UNCLASSIFIED 


_ AD  NUMBER _ 

ADB020488 

LIMITATION  CHANGES 
TO: 

Approved  for  public  release;  distribution  is 
unlimited. 


FROM: 

Distribution  authorized  to  U.S.  Gov't,  agencies 
only;  Proprietary  Information;  NOV  1976.  Other 
requests  shall  be  referred  to  Air  Force 
Armament  Laboratory,  ATTN:  DLMM,  Eglin  AFB,  FL 
32542. 


_ AUTHORITY 

ADTC  Itr  dtd  23  Oct  1979 


THIS  PAGE  IS  UNCLASSIFIED 


/ 


/ 

/ 

THir  REPORT  HAS  BEEN  DELI KITED 
and  CLEARED  FOR  PUBLIC  RELEASE 
UNDER  DOD  DIRcCTIVE  5200.20  MiD 

NO  RESTRICTIONS  ARE  IMPOSED  UPON 
ITS  USE  AND  DISCLOSURE! 

distribution  STA.TEtCHT  A 

approved  for  public  release; 
distribution  UNLIMITED, 


FILE  (iopy  AD  B  0  2  0  4  8 


DIGITAL  OUIDID  WEAPONS  TECHNOLOGY 
VOLUME  II:  SYSTEM  SIMULATIONS 


Distribution  United  to  U.  S.  Government  agencies  only; 
this  report  documents  test  and  evaluation;  distribution 
limitation  applied  November  1976.  Other  requests  for 
this  dicuitent  must  be  referred  to  the  Air  Force  Armament 
Laboratory  (DUiOi  Eglin  Air  Force  Base,  Florida  32542. 


AIR  FORCE  ARMAMENT  LABORATORY 


UNCLASSIFIED 

security  classification  of  this  page  (tVhnn  Data  Enlared) 

I  /i^)report  documentation  page 


111.  REPOR1 


^  GOVT  ACCESSION  NO 


AFATLHyR-76-132^VolfrlMiClT.-4Jf _ 

4.  title  (’and  Subtitle)  _ _ ^ 

DIGITAL;  GUIDED  ,)yEAPONS,TECHNOLOGY 
'volume ^r»  SYSTEM  SIMULATIONS  ♦ 


READ  INSTRUCTIONS 

_ BEFORE  COMPLETING  FORM 

3j„>4»^CIPI ENT’S  CATALOG  NUMBER 


Final  ^epoVt#  AugWPl  11^74' 
O  NovMihiM^ 


R.AVoolle^  j  D./Sobek  1 
R./Hoolko^  V  F. /Watson  \ 

T  yMniif  r.n^  - - .A 

PERFORmUI^ORGANIZATION  NAME  AND  ADDRESS 

Hughes  Aircraft  Company  > 

Missile  Division 

Canoga  Park,  California  91 304 

11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS  y 

Air  Force  Armament  Laboratory  / 

Armament  Development  and  Test  Center  s 
Eglin  Air  Force  Base,  Florida  32542 

14.  monitoring  AGENCY  NAME  A  AODRESSC// d/f/aran(  t'om  Controllini 


IAC>Ref^&iwe*»MoUD30(y3) 

:ONTRACT  OR  GRANT  NUM^Rfa; 


ti 


F^'8635-75-C-4014 


10.  program  ELEMENT,  PROJECT,  TASK 
AREA  &  WORK  UNIT  NUMBERS 

Project  No.  670E>  , 

Task  No,  01 
Work  Unit  No.  )^14 
1 12.  - 


»76 


15.  SECURITY  CLASS,  (ot  thia  report) 

Unclassified 


ISa.  DECLASSIFICATION/ DOWNGRADING 
SCHEDULE 


I  16.  distribution  STATEMENT  (ot  title  Report) 


Distribution  limited  to  U.S.  Government  agencies  only;  this  report  documents 
test  and  evaluation;  distribution  limitation  applied  November  1976.  Other 
requests  for  this  document  must  be  referred  to  the  Air  Force  Armament 
Laboratory  (DLMMj ,  Eglin  Air  Force  Base,  Florida  32542. 


17.  distribution  statement  (oI  the  abelraci  entered  In  Block  20,  It  dlllerent  Irom  > 


Trm 


18.  SUPPLEMENTARY  NOTES 


Available  in  DDC. 


19.  KEY  WORDS  (Continue  on  reverte  «/de  it  necetemry  and  identify  by  block  number) 


Digital  Processors 
System  Component  Integration 
Advanced  Modular  Weapon  System 
Performance  Evaluation 
Navigation  Accuracy _ 


Aided  Inertia.  Midcourse  Guidance 
Long-Range  jUr -to -Surface  Weapon 
Hybrid  Com. outer  Simulation 
LORAN  Sensor 
Software  Documentation 


20.  ABSTRACT  (Continue  on  revetee  aide  It  neceeemry  and  Identify  by  block  number) 

"  ^  This  report  describes  simulations  and  field  tests  performed  with  the 

two  digital  processing  systems,  DPI  and  DP2,  which  were  built  on  the 
Digital  Guided  Weapons  Technology  Program.  The  DPI  system  was  inte¬ 
grated  with  a  GFE  Inertial  Measurement  Unit  (IMU);  and,  after  testing  at 
Hughes  Aircraft  Company,  it  was  integrated  with  the  Completely  Integrated 
Reference  Instrumentation  System  (CIRIS)  at  the  Central  Inertial  Guidance 
Test  Facility  (CIGTF),  Holloman  Air  Force  Base,  New  Mexico.  Peifor - - 


FORM 
1  JAN  71 


EDITION  OF  1  NOV  65  IS  OISOLETE 

-5  878 


UNCLASSIFIED  y 

SECURITY  CLASSIFICATION  OF  THIS  PAGE  flWi«n  Data  Entered) 


'»V-4 


UNCLASSIFIED 


security  classification  of  this  PAOErWhwi  Oala  BnlaraO 


20.  ABSTRACT  (CONCLUDED) 

X^mance  tests  were  carried  out  by  the  Air  Force  in  the  laboratory,  in  a  van, 
and  in  an  aircraft.  Performance  in  navigation  accuracy  relative  to  CIRIS 
was  determined.  The  DP2  system  was  integrated  into  a  semiphysical 
hybrid  computer  simulation  at  the  contractor  facility.  The  simulation 
performed  was  that  of  a  long-range  air-to-surface  weapon  which,  uses  an 
aided  inertial  guidance  system  for  midcourse  guidance.  A  simulated  LORAN 
sensor  was  used  to  update  the  inertial  navigation  subsystem.  The  DP2  soft¬ 
ware  included  Management  and  Executive  Software  and  the  following  compu¬ 
tational  elements:  LORAN  processing,  alignment  filter  midcourse  guidance 
law,  navigation,  and  flight  control. 


UNCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGErNTion  Oala  Enlarad; 


PREFACE 


This  final  report  was  prepared  by  the  Missile  Division,  Hughes 
Aircraft  Company,  Canoga  Park,  California  91304,  under  Contract  No. 
F08635- 75-C- 00 14  with  the  Air  Force  Armament  Laboratory,  Armament 
Development  and  Test  Center,  Eglin  Air  Force  Base,  Florida.  Major 
Robert  L.  Haney  (DLMM)  monitored  the  program  for  the  Armament 
Laboratory.  This  effort  was  conducted  during  the  period  from  August  1974 
to  November  1976. 

This  report  consists  of  three  volumes.  Volume  I  contains  Digital 
Processor  System  Studies.  Volume  II  is  concerned  with  System  Simula¬ 
tions.  Volume  III  deals  with  a  Programmable  Digital  Autopilot.  This  is 
Volume  II. 

This  technical  report  has  been  reviewed  and  is  approved  for 
publication. 

FOR  THE  COMMANDER: 


,  USAF 


ACCESSION  for 
NTIS  White  Section 

DOC  Buff  Section 

UNANNOUNCED 

JUSTIFICATION  _ 


BY  _ 


OISTRIBmiON/AVAllABIllTT  COOES 

Dlst.  AVAIL.  anJ/or  SPECIAL 


i 

(The  reverse  of  this  page  is  blank. ) 


Section 

I 

II 

III 

IV 


TABLE  OF  CONTENTS 


Title  Page 

INTRODUCTION  1 

DIGITAL  PROCESSING  SYSTEM 

Digital  Processing  System  Hardware  3 

Executive  3 


CENTRAL  INERTIAL  GUIDANCE  TEST  FACILITY 
OPERATION 

System  Description  45 

System  Tests  70 

HYBRID  SIMULATION 

System  Description 
Simulation  Implementation 
System  Integration  and  Running  Simulation 


101 

103 

143 


LIST  OF  FIGURES 


Figure  Title  Page 

1  DP  System  Block  Diagram  4 

2  Executive  Routines  and  Data  Bases  4 

3  Task  Supervisor  Resource  Hierarchy  7 

4  Task  Queueing  Routine  (TASKQU)  ^ 

5  TASKQU  Flowchart  8 

6  Task  Dispatching  Routine  (DISPAT)  9 

7  DISPAT  Flowchart  10 

8  Search  TQ  for  Highest  Priority  Task  Routine  (SEARCH)  12 

9  SEARCH  Flowchart  13 

10  Save  Routine  (SAVE)  14 

11  Restore  Routine  (RESTOR)  15 

12  Task  ID  Table  (IDTABL)  16 

13  DataBase  Supervisor  Resources  18 

14  DataBase  Supervisor  Routine  (DBSUPR)  19 

15  DBSUPR  Flowchart  20 

16  Data  Bus  Driver  Routine  (DBDRV)  21 

17  DBDRV  Flowchart  22 

18  Message  Queue  Insert  Routine  and  Flowchart  (MQINSE)  23 

19  Message  Queue  Remove  Routine  (MQREMO)  24 

20  MQREMO  Flowchart  25 

21  Data  Bus  Complete  Interrupt  Routine  (DBCOMP)  26 

22  DBCOMP  Flowchart  28 

23  Data  Bus  Error  Routine  (DBERR)  v  29 

24  DBERR  Flowchart  30 

25  Message  Queue  Structure  30 

26  Message  Parameter  Table  30 

27  Interrupt  Bus  Supervisor  (IBUSSU)  31 

28  Interrupt  Bus  Interrupt  Routine  (IBUSIN)  31 

29  IBUSSU  Flowchart  32 

30  IBUSIN  Flowchart  32 

31  Clock  Interrupt  Routine  (CLKINT)  34 

32  Clock  Table  -  Entry  Routine  and  Flowchart 

(CLKTAB)  35 


IV 


LIST  OF  FIGURES  (Continued) 
Title 


Figure 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 


Clock  Table  -  Remove  an  Entry  (CLKREM) 

CLKREM  Flowchart 

CLKINT  Flowchart 

Test  Interrupt  Routine  (TESINT) 

TESINT  Flowchart 

PRICHG,  PRIRES  and  RSTINT  Routines 
Linkage  Tables 

Digital  Processing  System  (CIGTF)  Block  Diagram 
Rack  Layout 

Completely  Integrated  Reference  Instrumentation 
System  (CIRIS) 

DPI  Block  Diagram 

Control  Panel 

Time  Sync  Interrupt  Sequence 

Reference  Data  Ready  Interrupt  Processing 

Navigation  Initialization  and  Initiation 

IMU  Data  Formatting  and  1  ransfer 

Navigation  Computations 

Altimeter  Data  Sequence 

Alignment  Initialization  and  Computation 

IMU  Data  Accumulation 

Instrumentation  Data  Transfer  Sequence 

Self  Test 

Navigation  Error  After  10  Minutes 

Coning  Motion  Z  Axis,  Error  Relative 

to  Analytic  Solution 

Compensation  Software  Test  Setup 

DGWT  Laboratory  Tests 

HS  3030  Sensor  Axes 

Typical  Velocity  Profiles,  Runs  1  Through  3 
Typical  Velocity  Profiles,  Runs  5  and  6 
Misalignment  Assumption 


Page 

35 

36 

37 

38 

38 

39 
39 
42 
45 

47 

49 

51 

54 

56 

57 

58 

59 
61 
62 
63 

63 

64 

72 

73 

78 

79 

80 

91 

92 
92 


V 


LIST  OF  FIGURES  (Concluded) 


'  *K 

.  ‘S'-  ■■•• 

■  -J 


Figure 

Title 

Page 

63 

Weapon  to  be  Simulated 

102 

64 

Inertial  Navigation  Update  Guidance  System 

105 

65 

DP  Hybrid  Simulation 

105 

66 

Block  Diagram  of  Hardware  Interfaces  Used  in 

Simulation 

106 

67 

Baseline  Simulation  Functional  Block  Diagram 

108 

68 

Block  Diagram  of  Additions  to  GBU-15  Simulation  for 
LORAN  Receiver  Type  Information 

109 

69 

Block  Diagram  Showing  Functions  and  Data  Flow  in  DP 

111 

70 

DP2  Software  Functional  Block  Diagram 

118 

71 

FCADX  Flowchart 

120 

72 

Couter  Flowchart 

121 

73 

Navigation  Software  Task  Flowchart 

122 

74 

Illustration  of  Trajectories  Resulting  from  Guidance  Law 
With  and  Without  Limiting  of  (cTrT  -  o'lio)  Term  in 

Calcul  ations 

124 

75 

Guidance  Law  Software  Initialization 

125 

76 

Guidance  Law  Flow  Diagram  Task  60 

126 

77 

Sequence  of  Interrupts  from  SIGMA  8  to  DP 

129 

78 

System  Initialization  Interrupt  Sequence 

132 

79 

Pseudo -Alignment  Interrupt  Sequence 

133 

80 

Target  Information  Interrupt  Sequence 

135 

81 

LORAN  Initialization  Interrupt  Sequence 

136 

82 

Weapon  Separate  Interrupt  Sequence 

137 

83 

LORAN  Receiver  Interrupt  Sequence 

138 

84 

Midcourse  Guidance  Interrupt  Sequence 

139 

85 

Run  Termination  Interrupt  Sequence 

141 

86 

400  Hz  Interrupt  Sequence 

142 

87 

10  Hz  Interrupt  Sequence 

143 

88 

Case  1  Trajectories 

149 

89 

Case  2  Trajectories 

150 

90 

Case  3  Trajectories 

150 

91  ' 

Case  4  Trajectories 

152 

92 

Case  5  Trajectories 

152 

VI 


#■ 


LIST  OF  TABLES 


Table  Title  Page 

1  HS-3030  Inertial  Measurement  System  Characteristics  45 

2  DPI  Parameters  50 

3  Weapon  Bus  Parameters  53 

4  Software  Modules  56 

5  Experimental  versus  Analytic  Results  after  5  minutes 

(299.9  seconds)  76 

6  Gyro  Compensation  Analysis  81 

7  Static  Test  Summary  of  28-30  September  1976  87 

8  Static  Test  Summary  of  26-28  October  1976  89 

9  Calibration  Analysis  Summary  93 

10  Gyro  Compensation  Analysis  97 

11  Van  Test  Summary  of  9  November  -  11  November  1976  98 

12  Interface  Signals  Between  the  Analog  Computer  and 
Digital  Processor  (DP)  During  Hybrid  Simulation 

(Digital  Guided  Weapons  Technology  Program)  113 

13  Discrete  Logic  Variables  115 

14  Variables  Passed  Over  Digital  Interface  116 

15  SIGMA  8  Interrupts  and  Responses  of  the  Digital 

Processor  (CP)  130 

16  Test  Conditions  for  Simulation  Runs  149 


vii 

(The  reverse  of  this  page  is  blank) 


SECTION  I 


INTRODUCTION 


The  Digital  Guided  Weapon  Technology  (DGWT)  program  was  initiated 
with  the  general  intent  of  determining  the  role  of  digital  processing  techniques 
in  guided  weapons.  Recognizing  that  too  broad  a  scope  can  be  self-defeating 
for  this  kind  of  program,  the  Air  Force  set  two  specific  goals  to  be  accom¬ 
plished.  The  first  was  a  near  term  application  of  digital  processing  to  an 
existing  weapon  family.  Specifically,  a  digital  autopilot  for  the  GBU-15 
weapon  was  to  be  designed  and  evaluated.  The  evaluation  required  fabrica¬ 
tion  of  a  brassboard  digital  processor  for  the  autopilot  and  verification  of 
its  performance  with  a  hybrid  simulation.  That  part  of  the  program  was 
completed  in  1975.  A  separate  program  was  initiated  to  bring  the  GBU-15 
digital  autopilot  into  engineering  development  based  on  the  results.  The 
Programmable  Digital  Autopilot  (PDAP)  work  is  reported  in  Volume  III  of 
this  final  report. 

The  second  goal  was  to  determine  how  digital  processing  techniques 
could  be  used  to  assist  in  integrating  the  components  of  an  advanced  modular 
weapon  system.  Earlier  studies  sponsored  by  the  Air  Force  had  investigated 
the  characteristics  of  a  modular  weapon.  The  results  of  one  of  these  studies, 
as  expressed  in  AFATL-TR-72-Z0Z,  were  used  as  a  starting  point 
to  define  the  weapon  system  to  be  studied  in  the  DGWT  program.  Specifically, 
the  program  was  to  accomplish  the  following  objectives: 

1.  Determine  which  functions  dould  be  done  digitally  in  the  weapon 
system. 

Z.  Determine  what  the  digital  processing  system  should  do  to 
assist  in  integrating  the  weapon  components. 

3.  Determine  which  other  functions  should  be  done  in  the  digital 
processor. 

4.  Define  the  interfaces  of  the  digital  processing  subsystem  within 
the  weapon  system. 

5.  Determine  the  requirements  of  the  digital  processing  system. 

6.  Produce  a  preliminary  design  of  the  digital  processing  system. 

7.  Build  two  breadboard  processing  systems. 


8.  Evaluate  the  breadboard  systems  in  hybrid  simulation  and 
other  tests. 


All  of  these  objectives  were  accomplished.  The  work  performed  and 
results  achieved  relative  to  the  first  six  objectives  are  reported  in  Volume  I, 
Digital  Processor  System  Studies.  That  volume  describes  the  digital  process 
ing  system  recommended  to  perform  the  integration  function  in  an  advanced 
modular  weapon.  The  work  done  relative  to  the  seventh  and  eighth  objectives 
is  reported  here  in  Volume  II. 

To  fulfill  the  seventh  objective,  two  breadboarded  digital  processing 
systems,  DPI  and  DP2,  were  constructed.  The  first  of  these,  the  DPI  sys¬ 
tem  was  integrated  with  an  inertial  measurement  unit  (IMU)  furnished  by  the 
Air  Force,  and  after  tests  at  Hughes  Aircraft  Company,  was  shipped  to  the 
Central  Inertial  Guidance  Test  Facility  (CIGTF)  at  Holloman  Air  Force  Base 
in  New  Mexico.  At  CIGTF,  the  DPI  system  was  integrated  with  CIRIS  (Com¬ 
pletely  Integrated  Reference  Instrumentation  System)  and  then  underwent 
performance  tests  under  the  direction  of  the  Air  Force.  In  addition  to  labora 
tory  tests,  the  system  was  tested  in  a  van,  on  surface  roads,  and  also  in  an 
aircraft. 

The  DP2  system  was  integrated  into  a  six-degree-of-freedom  (6DOF) 
hybrid  computer  simulation  of  the  GBU-15  cruciform  wing  weapon  in  the 
Hughes  Hybrid  Computer  Laboratory  at  Canoga  Park.  The  simulation  was 
performed  to  investigate  the  use  of  aided  inertial  guidance  for  midcourse. 

Detailed  information  about  these  two  breadboarded  systems,  DPI  and 
DP2,  and  about  the  related  software  developed  for  the  simulations  and  tests 
performed  is  contained  in  the  following  documents  and  reports; 

1.  Operating  Manual  and  System  Description  for  Digital  Processor 
Number  1,  Report  No.  DGWT  0210-1,  Revision  A. 

2.  Operating  Manual  and  System  Description  for  Digital  Processor 
Number  2,  Report  No.  DGWT  0210-2. 

3.  Programmer's  Manual  for  PDAP,  DPI  and  DP2,  Report  No. 
DGWT  0170-2. 

4.  Digital  Processor  System  Specification,  Report  No.  DGWT 
0240-1. 

5.  Digital  Processor  Software  Development  Report,  Report  No. 
DGWT  0165-1. 

This  Volume  II  provides  a  brief  description  of  the  system  hardware, 
the  documentation  for  the  system  execitive  software,  and  a  detailed  des¬ 
cription  of  the  actual  tests  and  simulations  involving  the  two  systems,  DPI 
and  DP  2. 
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SECTION  II 


DIGITAL  PROCESSING  SYSTEM 


The  basic  digital  processing  (DF)  system  is  composed  of  a  digital 
processor,  a  weapon  bus  and  the  executive  software.  In  an  operating  system, 
there  will  be  other  subsystems  which  must  be  interfaced  with  the  DP.  The 
interface  is  accomplished  by  means  of  a  Bus  Interface  Unit  (BIU),  which  pre¬ 
sents  a  common  interface  to  the  bus,  and  the  executive  software.  In  prac¬ 
tice,  most  existing  subsystems  are  not  directly  compatible  with  the  common 
BIU  interface,  therefore,  additional  interfacing  equipment  is  required. 

This  was  true  for  all  the  subsystems  used  in  the  CIGTF  operation  and  the 
simulations. 

The  executive  software  is  common  to  all  configurations.  It  acts  as 
the  software  interface  between  the  external  world  and  the  DP  system.  In 
addition,  it  interfaces  between  the  various  applications  software  modules 
which  the  system  requires,  When  applications  software  modules  (e.g,  , 
inertial  navigation)  are  added  to  the  system,  it  is  also  necessary  to  add 
special  interfacing  software  modules  to  allow  the  executive  to  do  its  job. 
These  special  modules  are  part  of  the  System  Management  function, 

DIGITAL  PROCESSING  SYSTEM  HARDWARE 

The  basic  DP  hardware  is  shown  in  Figure  1.  Figure  1  illustrates 
how  external  subsystems  can  be  integrated  into  the  system.  The  Control 
Panel,  used  in  system  development,  allows  monitoring  and  control  of  sys¬ 
tem  functions.  It  would  not  be  present  in  a  tactical  weapon  installation. 

The  digital  processor  (DP)  is  a  rack-mounted  breadboard  unit.  The  BIU's 
are  separate  units  which  terminate  sections  of  the  weapon  bus.  The  proces¬ 
sor  in  the  DP2  system  differs  from  the  DPI  processor  in  having  an  enlarged 
instruction  set  and  in  having  the  Master  Bus  Control  in  the  DP  rather  than 
in  the  BIU  box  as  in  DPI.  Further  details  of  the  hardware  are  contained  in 
Sections  III  and  IV.  For  a  complete  description,  the  reader  is  referred  to 
the  DPI  and  DP2  System  Description  Manuals,  Reports  DGWT  0210-1  and 
DGWT  0210-2,  respectively, 

EXECUTIVE 

The  executive  is  an  organized  collection  of  software  routines  (shown 
in  Figure  2)  designed  to  manage  the  processor  resources.  It  is  responsible 
for  interfacing  with  all  interrupt  hardware  and  input/output  equipment  and 
for  supervising  the  execution  of  all  software  modules.  The  executive  acts 
as  a  buffer  between  software  modules  and  the  hardware  by  performing  all 
input/output  operations,  thereby  making  software  modules  independent  of 
the  mechanization  of  input/output  hardware.  It  also  acts  as  a  buffer  between 
software  modules,  providing  a  common  way  of  interfacing  one  module  to 
another.  The  isolation  provided  by  the  executive  reduces  the  likelihood  that 
changes  made  in  one  software  module  will  propagate  into  other  modules.  It 
also  makes  it  a  relatively  easy  matter  to  add  more  functions  to  the  system. 
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The  executive  is  a  permanent  part  of  the  system  that  is  common  to  all 
configurations. 

The  processor  functions  are  partitioned  into  units  called  tasks.  Each 
task  is  a  unit  of  work  that  is  to  be  performed  as  a  result  of  some  external 
event  or  time  event  or  command  from  another  task.  Tasks  can  range  in 
size  from  a  few  instructions  to  a  few  hundred  instructions,  and  in  execution 
time  from  microseconds  to  seconds.  Some  tasks  may  only  be  executed  once 
while  others  may  be  executed  from  100  to  400  tirnes  per  second.  They  are 
characterized  by  a  unique  identification  number,  a  starting  address,  and  a 
priority.  Tasks  are  called  by  each  other  or  associated  with  external  events 
only  by  their  ID  number.  Only  the  executive  needs  to  know  the  location  and 
priority  of  a  task,  and  since  this  information  is  contained  in  a  table,  it  can 
vary  from  one  configuration  to  another  without  the  tasks  having  to  be  changed. 

In  determining  how  to  partition  a  processor  function  into  tasks,  some 
general  rules  should  be  followed; 

1.  Each  task  should  consist  of  a  single  operation  at  some  level  of 
abstraction  in  the  description  of  the  function.  At  a  lower  level  of 
abstraction  the  task  might  include  many  operations  but  there 
should  be  some  level  at  which  the  programmer  can  consider  the 
task  as  s  single  operation.  Otherwise,  it  should  be  broken  down 
into  smaller  tasks. 

2.  A  task  should  not  have  delay  loops  longer  than  30  microseconds 
in  it  that  wait  for  some  external  event  to  be  completed.  If  a  task 
must  initiate  an  external  event,  such  as  the  transmission  of  a 
block  of  data  from  a  weapon  subsystem  to  the  DP,  and  has  no 
other  operations  to  perform  until  the  data  block  has. been 
received  by  the  DP,  then  it  should  be  broken  into  two  tasks.  The 
first  task  would  initiate  the  external  event  and  then  end  by 
returning  to  the  executive.  The  second  task  would  execute  when 
the  data  transfer  is  complete.  During  the  time  in  between,  the 
executive  can  start  executing  some  other  task  so  the  time  is  not 
wasted. 

3.  A  task  should  not  have  a  small  subset  of  operations  that  have  a 
much  higher  priority  than  the  bulk  of  the  task.  Instead  it  should 
be  partitioned  into  two  tasks  which  have  different  priority  levels. 
One  task  containing  the  bulk  of  the  operations  would  run  at  a  low 
priority,  and  the  remaining  few  operations  would  be  performed 
in  a  separate  task  at  a  higher  priority. 

All  these  task«  must  be  tied  together  and  executed  in  a  sequence 
appropriate  to  the  weapon  configuration.  This  will  be  accomplished  by  two 
levels  of  software.  One  of  these  levels  is  the  executive  which  causes  soft¬ 
ware  modules  to  be  executed  in  response  to  signals  from  external  devices  or 
in  response  to  commands  from  other  software  modules.  The  executive  does 
this  without  any  knowledge  of  the  weapon  configuration  or  what  each  module 
is  supposed  to  do.  This  knowledge  is  contained  in  the  system  management 
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module  which  is  the  second  level  of  software  that  controls  the  sequence  of 
execution  of  all  tasks.  The  system  management  function  is  described  in 
software  subsections  of  Sections  III  and  IV. 


The  remainder  of  the  EXECUTIVE  subsection  discusses  the  various 
components  of  the  executive. 

Task  Supervisor 

The  purpose  of  the  task  supervisor  is  to  supervise  the  execution  of 
all  tasks  in  the  DP  assuring  that  high  priority  tasks  take  precedence  over 
low  priority  tasks.  The  task  supervisor  consists  of  the  task  queueing  rou¬ 
tine  TASKQU,  the  task  dispatching  routine  DISPAT,  the  queue  searching 
routine  SEARCH,  the  ID  table  IDTAB,  and  the  task  queue  TQ.  The  hierarchy 
of  these  routines  is  shown  in  Figure  3. 

TASKQU.  The  purpose  of  the  task  queueing  routine  shown  in  Figure  4  is  to 
place  the  address  and  priority  of  a  task  in  the  TASK  QUEUE. 

It  can  be  called  by  interrupt  routines  or  by  any  task.  When  called, 
TASKQU  looks  up  the  address  and  priority  of  the  task  in  the  TASK  ID  TABLE 
and  places  them  in  the  TASK  QUEUE  which  is  an  unordered  list.  It  also 
compares  the  priority  of  the  task  being  placed  in  the  queue  with  the  CURRENT 
TASK  PRIORITY.  If  the  priority  of  the  new  task  is  higher  it  sets  a  flag 
called  HIGH  PRIORITY  TASK  WAITING.  It  then  returns  to  the  program  that 
called.  The  calling  program  may  look  at  the  HIGH  PRIORITY  TASK 
WAITING  flag  to  decide  whether  to  go  to  the  task  DISPATCHER  immediately 
or  not.  The  flowchart  for  TASKQU  is  shown  in  Figure  5. 

DISPAT.  The  purpose  of  the  task  dispatching  routine  shown  in  Figure  6  is 
to  search  the  TASK  QUEUE  for  the  highest  priority  task,  and  if  this  task  has 
a  higher  priority  than  the  CURRENT  TASK  PRIORITY,  then  the  task  should 
be  removed  from  the  queue  and  executed. 

DISPAT  includes  the  routine  SEARCH. 

DISPAT  can  be  called  by  any  program  that  queues  up  a  task  although 
it  is  not  necessary.  All  tasks  are  called  by  the  dispatcher  so  all  tasks 
return  to  the  dispatcher  by  executing  an  RTN  when  they  are  finished. 

When  it  is  called  DISPAT  first  clears  the  HIGH  PRIORITY  TASK 
WAITING  flag  if  it  is  set  and  saves  processor  status.  It  then  searches  the 
TASK  QUEUE  for  the  highest  priority  task.  If  the  highest  priority  task  in 
the  queue  is  higher  in  priority  than  the  CURRENT  TASK  PRIORITY,  then 
the  dispatcher  removes  that  task  from  the  queue  and  calls  it.  When  the 
task  is  finished,  it  executes  a  return  instruction  returning  it  to  the  dis¬ 
patcher.  The  dispatcher  then  searches  the  TASK  QUEUE  again  for  the 
highest  priority  task.  When  the  highest  priority  task  in  the  queue  has  lower 
priority  than  the  CURRENT  TASK  PRIORITY,  the  dispatcher  restores  the 
processor  status  and  executes  a  return  instruction.  The  flowchart  for 
DISPAT  is  shown  in  Figure  7, 
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Figure  3.  Task  Supervisor  Resource  Hierarchy 
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Figure  4.  Task  Queueing  Routine  (TASKQU) 
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Figure  6,  Task  Dispatching  Routine  (DISPAT) 
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Figure  7.  DISPAT  Flowchart 


SEARCH.  The  purpose  of  the  SEARCH  routine  shown  in  Figure  8  is  to 
search  the  task  queue  for  the  highest  priority  task. 

SEARCH  is  only  called  by  DISPAT.  When  called,  it  searches  the 
task  queue  for  the  highest  priority  task.  It  returns  the  highest  priority  in 
the  queue  in  latch  2  and  the  location  in  the  queue  of  the  highest  priority  task 
in  index  register  1.  If  the  queue  was  empty,  it  returns  a  zero  in  latch  2. 

The  flowchart  for  SEARCH  is  in  Figure  9. 

SAVE  and  RESTORE.  The  purpose  of  the  routines  SAVE  and  RESTORE  (see 
Figures  10  and  11,  respectively)  is  to  save  the  status  of  the  processor  when 
a  task  is  going  to  be  interrupted  by  another  task  and  to  restore  the  status  of 
the  processor  when  the  interrupted  task  is  to  be  resumed. 

SAVE  pushes  the  contents  of  the  two  latches,  the  carry  bit,  the  shift 
counter,  memory  location  JMPLNK,  and  index  registers  0  through  5  onto  the 
stack.  RSAVE  is  used  when  only  the  latches  and  carry  bit  need  to  be  saved. 

RESTORE  restores  the  contents  of  the  two  latches,  the  carry  bit,  the 
shift  counter,  memory  location  JMPLNK,  and  index  registers  0  through  5 
from  the  stack.  RREST  restores  only  the  two  latches  and  the  carry  bit. 

Task  ID  Table.  The  TASK  ID  TABLE  shown  in  Figure  12  stores  the  starting 
address  and  priority  of  each  of  the  tasks  in  the  DP.  The  routine  IDTABL, 
also  shown  in  Figure  12,  puts  entries  in  the  table. 

THE  STACK.  The  STACK  is  a  push  down  (last  in  first  out)  stack  imple- 
mented  in  operand  memory  with  index  register  31  used  as  the  stack  pointer. 
The  stack  expands  downward  in  memory  toward  location  0.  The  stack 
pointer  normally  points  to  the  last  occupied  position  in  the  stack.  To  push 
an  item  onto  the  stack  the  stack  pointer  should  be  decremented  by  one  and 
then  the  item  should  be  stored  in  the  stack  at  the  location  indicated  by  the 
stack  pointer.  When  popping  an  item  off  the  stack  the  item  should  first  be 
read  from  the  stack,  then  the  stack  pointer  should  be  incremented. 

Data  Bus  Supervisor 

The  purpose  of  the  data  bus  supervisor  is  to  maintain  a  queue  of 
messages  to  be  transmitted  on  the  data  bus,  and  to  schedule  the  messages 
according  to  priority. 

The  data  bus  supervisor  is  called  by  tasks  when  data  is  to  be  sent  on 
the  data  bus.  If  the  bus  is  available,  the  message  is  sent  immediately. 
Otherwise,  the  message  is  queued  up  to  be  transmitted  when  the  data  bus 
becomes  available.  The  data  bus  supervisor  includes  a  routine  to  put 
messages  in  a  queue  (MQINSE),  a  routine  to  remove  messages  from  the 
queue  (MQREMO),  a  driver  for  the  data  bus  (DBDRV),  an  interrupt  routine 
to  handle  the  normal  completion  of  a  message  (DBCOMP),  and  an  interrupt 
routine  to  handle  error  conditions  (DBERR).  Each  block  of  data  to  be  trans¬ 
mitted  on  the  data  bus  is  called  a  message  and  must  have  a  Message  Param¬ 
eter  Table  associated  with  it  that  contains  descriptions  of  the  source  and 
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Figure  10.  Save  Routine  (SAVE) 
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Figure  11.  Restore  Routine  (RESTOR) 
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destination  of  the  message,  the  number  of  words  in  the  message,  the  priority 
of  the  message,  and  the  ID  number  of  a  task  to  be  queued  up  when  the  mes¬ 
sage  has  been  transmitted.  The  data  bus  supervisor  is  shown  in  Figure  13. 

DBSUPR.  To  send  a  block  of  data  on  the  weapon  bus,  a  task  puts  the 
address  of  a  message  parameter  table  in  index  register  0  and  calls  the  data 
bus  supervisor  (DBSUPR).  DBSUPR  (shown  in  Figure  14)  checks  to  see  if 
the  bus  is  busy.  If  the  bus  is  not  busy,  DBSUPR  calls  the  data  bus  driver 
(DBDRV)  to  send  the  data.  If  the  bus  is  busy,  DBSUPR  calls  the  message 
queue  insert  routine  (MQINSE)  to  put  the  message  in  the  message  queue  for 
later  transmission.  The  flowchart  of  DBSUPR  is  shown  in  Figure  15. 

DBDRV.  The  data  bus  driver  is  the  interface  between  the  rest  of  the  soft¬ 
ware  and  the  weapon  bus.  Figure  16  shows  the  data  bus  driver  routine. 

It  takes  parameters  from  the  message  parameter  table,  transforms  them  if 
necessary,  and  writes  them  in  the  I/O  registers  for  the  weapon  bus.  After 
the  parameter  describing  the  source,  destination,  and  size  of  the  data  block 
have  been  given  to  the  bus  master,  DBDRV  sends  the  Start  Data  Transfer 
signal  and  returns  to  the  calling  routine.  While  the  weapon  bus  is  transmit¬ 
ting  the  block  of  data,  the  DP  is  free  to  resume  executing  tasks.  The  flow¬ 
chart  of  DBDRV  is  shown  in  Figure  17. 

MQINSE.  The  message  queue  insert  routine  shown  in  Figure  18  places  the 
address  index  register  0  in  the  message  queue.  The  address  in  index 
register  0  is  assumed  to  be  the  address  of  a  message  parameter  table. 

The  flowchart  for  MQINSE  is  also  shown  in  Figure  18, 

MQREMO.  The  message  queue  remove  routine  shown  in  Figure  19  searches 
the  queue  looking  for  the  highest  priority  message  in  the  queue.  It  does  this 
by  looking  at  the  priority  word  in  each  message  parameter  table  listed  in  the 
queue.  If  there  are  several  messages  at  the  same  priority  level,  the  one 
closest  to  the  bottom  of  the  queue  (oldest  message)  will  be  chosen.  The  sel¬ 
ected  message  is  removed  from  the  queue  and  the  address  of  the  message 
parameter  table  is  placed  in  index  register  23.  If  there  are  no  messages  in 
the  queue,  a  0  is  placed  in  index  register  23,  The  flowchart  for  MQREMO 
is  shown  in  Figure  20. 

DBCOMP.  The  data  bus  complete  routine  shown  in  Figure  21  is  an  interrupt 
service  routine  that  is  executed  when  the  bus  master  determines  that  the 
message  has  been  transmitted  correctly.  DBCOMP  clears  a  status  bit  in 
the  message  parameter  table  of  the  message  just  completed.  This  feature 
is  useful  only  if  the  message  parameter  table  is  in  read/write  memory. 
DBCOMP  also  checks  the  status  word  of  the  message  parameter  table  to 
determine  which  task,  if  any,  is  to  be  executed  as  a  result  of  the  completion 
of  the  message  transmission.  If  the  task  ID  in  the  status  word  is  non  zero, 
that  task  is  queued  up  by  calling  the  task  queueing  routine  (TASKQU). 
DBCOMP  then  calls  the  message  queue,  remove  routine  (MQREMO)  which 
returns  the  address  of  the  highest  priority  message  in  the  message  queue. 

If  there  was  any  message  in  the  queue  the  data  bus  driver  (DBDRV)  is 
called  to  transmit  the  message.  DBCOMP  checks  the  "HIGH  PRIORITY 
TASK  WAITING"  flag  to  determine  whether  to  jump  to  the  dispatcher 
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Figure  13.  Data  Base  Supervisor  Resources 
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Figure  14.  Data  Base  Supervisor  Routine  (DBSUPR) 
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Figure  18.  Message  Queue  Insert  Routine  and  Flowchart  (MQINSE) 
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Figure  ZO..  MQREMO  Flowchart 
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Figure  Zl,  Data  Bus  Complete  Interrupt  Routine  (DBCOMP) 


(DISPAT)  or  to  just  return  to  the  interrupted  progralri.  The  flowchart  for 
DBCOMP  is  shown  in  Figure  22. 


DBERR.  The  data  bus  error  routine  shown  in  Figure  23  is  an  interrupt 
service  routine.  The  interrupt  occurs  when  the  bus  master  detects  that  an 
error  has  occurred  in  data  being  transmitted  on  the  bus.  DBERR  transfers 
data  from  the  active  message  parameter  table  to  an  empty  message  param¬ 
eter  table.  The  source  and  destination  addresses  and  the  word  count  are 
adjusted  to  account  for  the  number  of  words  already  sent,  and  the  data  bus 
driver  (DBDRV)  is  called  to  transmit  the  remainder  of  the  message. 
Whether  the  word  in  which  the  error  occurred  is  retransmitted  is 
determined  by  the  sign  bit  of  the  word  count.  If  the  sign  bit  is  one,  the 
word  in  which  the  error  occurred  is  retransmitted.  The  flowchart  for 
DBERR  is  shown  in  Figure  24. 

MQUE.  The  message  queue  shown  in  Figure  25  is  a  data  structure  which  is 
an  unordered  list  of  message  parameter  table  addresses.  The  pointer  con¬ 
tains  the  number  of  entries  in  the  queue  and  therefore  points  to  the  last 
entry  in  the  queue. 


Message  Parameter  Table.  The  message  parameter  tables  are 
tables  (one  ^or  eacli  message  as  shown  in  Figure  26)  describing  the  block  of 
data  to  be  transmitted  on  the  bus.  Each  one  describes  the  source,  destina¬ 
tion,  size,  and  priority  of  a  message,  and  also  indicates  which  task  is  to  be 
executed  when  the  message  has  been  transmitted. 

Interrupt  Bus  Supervisor 


The  purpose  of  the  interrupt  bus  supervisor  shown  in  Figure  27  is  to 
supervise  the  transmission  and  reception  of  interrupt  messages  on  the  inter¬ 
rupt  bus.  The  interrupt  bus  supervisor  includes  the  interrupt  bus  interrupt 
service  routine  (IBUSIN)  shown  in  Figure  28. 

To  send  an  interrupt  message  from  the  DP  to  an  external  device, the 
interrupt  bus  supervisor  (IBUSSU)  is  called  with  the  interrupt  message  in 
Latch  2.  IBUSSU  will  send  the  message  on  the  interrupt  bus  immediately  if 
the  bus  is  not  busy.  If  the  bus  is  busy,  IBUSSU  will  wait  long  enough  for  the 
bus  to  transmit  one  message  and  then  try  again.  The  flowchart  for  IBUSSU 
is  shown  in  Figure  29. 

Interrupt  Bus  Service  Routine.  The  interrupt  bus  service  routine  (IBUSIN) 
shown  in  Figure  28  is  executed  each  time  an  interrupt  message  is  received 
by  the  DP.  IBUSIN  gets  the  interrupt  from  the  bus  interface  unit  and  con¬ 
verts  the  message  into  a  task  ID.  It  then  calls  the  task  queueing  routine 
which  queues  up  the  appropriate  task.  IBUSIN  then  checks  the  HIGH 
PRIORITY  TASK  WAITING  flag,and,if  it  is  set,  jumps  to  the  dispatcher 
which  will  execute  the  task  just  queued  up.  If  the  flag  is  not  set,  IBUSIN 
returns  to  the  task  that  was  interrupted.  The  flowchart  for  IBUSIN  is  shown 
in  Figure  30. 


Figure  22.  DBCOMP  Flowchart 
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Figure  23.  Data  Bus  Error  Routine  (DBERR) 
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Figure  25.  Message  Queue  Structure 
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Figure  24.  DBERR  Flowchart 


Figure  26.  Message  Parameter  Table 
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Figure  27,  Interrupt  Bus  Supervisor  (IBUSSU) 
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Figure  28.  Interrupt  Bus  Interrupt  Routine  IBUSIN) 
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Clock  Supervisor 

The  purpose  of  the  clock  supervisor  is  to  process  the  400  Hz  clock 
interrupts  and  count  the  400  Hz  down  to  a  lower  iteration  rate  needed  by 
tasks  in  the  clock  table. 

The  clock  supervisor  includes  the  clock  interrupt  service  routine 
(CLKINT)  shown  in  Figure  31,  a  routine  to  place  tasks  in  the  clock  table 
(CLKTAB)  as  shown  in  Figure  32,  and  a  routine  to  remove  tasks  from  the 
clock  table  (CLKREM)  as  shown  in  Figure  33.  The  clock  table  contains  task 
ID's,  the  period  of  execution  of  each  task,  and  a  counter  for  each  task. 
CLKTAB  is  called  with  a  task  ID  in  latch  1  and  the  iteration  period  in  units 
of  2.  5  ms  in  latch  2.  CLKTAB  places  the  task  ID  and  its  period  in  the  clock 
table  and  sets  the  counter.  The  flowchart  for  CLKTAB  is  shown  in  Fig¬ 
ure  32.  CLKINT  is  executed  each  time  the  400  Hz  clock  signal  is  received. 
For  each  entry  in  the  table  the  counter  is  decremented  by  one.  If  the 
counter  has  reached  zero,  it  is  reset  to  the  period  and  the  task  is  queued  up 
by  calling  TASKQU.  The  flowchart  for  CLKINT  is  shown  in  Figure  35. 
CLKREM  is  called  with  a  task  ID  in  latch  2.  It  searches  the  clock  table  and 
removes  all  occurrences  of  the  task  ID  in  the  table.  The  flowchart  for 
CLKREM  is  shown  in  Figure  34. 

Test  Interrupt 

The  purpose  of  the  test  interrupt  service  routine  shown  in  Figure  36 
is  to  execute  a  test  task  each  time  the  test  interrupt  button  is  pushed. 

The  test  interrupt  routine  requires  that  the  test  tasks  be  numbered 
sequentially  and  has  a  counter  that  keeps  track  of  how  many  of  the  tests 
have  been  executed  so  far.  Each  time  the  test  interrupt  button  is  pushed, 
TSTINT  increments  its  counter  and  queues  up  the  next  task  in  the  sequence 
by  calling  TASKQU.  It  then  jumps  to  DISPAT  which  will  execute  the  task. 

The  flowchart  for  TESINT  is  shown  in  Figure  37. 

Interrupt  Priority  Level 

Latch  3  is  the  interrupt  priority  mask  register.  Only  interrupts  that 
have  a  priority  greater  than  the  contents  of  latch  3  can  interrupt  the  DP. 

The  contents  of  latch  3  can  be  temporarily  changed  without  losing  the  original 
contents  through  the  use  of  PRICHG  and  PRIRES  shown  in  Figure  38. 

PRICHG  saves  the  old  contents  of  latch  3  and  sets  a  new  level.  PRIRES 
restores  the  old  contents.  The  memory  word  INTPRI  normally  contains  the 
same  value  as  latch  3. 

RSTINT,  also  shown  in  Figure  38,  is  used  by  interrupt  routines  to 
clear  an  interrupt  request  that  is  being  processed  without  returning  to  the 
interrupted  program  yet. 
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Linkage  Tables 


The  executive  contains  linkage  tables  to  all  the  executive  subroutines 
and  interrupt  routines  that  could  be  entered  from  outside  the  executive  (see 
Figure  39).  This  allows  changes  to  be  made  in  the  executive  which  move  rou¬ 
tines  around  without  having  to  modify  any  external  routines  that  call  them. 
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Figure  31.  Clock  Interrupt  Routine  (CLKINT) 
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Figure  32.  Clock  Table  —  Entry  Routine  and  Flowchart  (CLKTAB) 
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Figure  33.  Clock  Table  —  Remove  an  Entry  (CLKREM) 
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Figure  34.  CLKREM  Flowchart 
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•  0 


COUNT  (I)  -  MAX  COUNT  (I) 

SET  HIGH  PRIORITY  TASK  WAITING 
PUT  TASK  (I)  IN  QUEUE 


Figure  35.  CLKINT  Flowchart 
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/  TEST  INTERRUPT  ROUTINE 


TESINT  GSBffRSAUE 
DAT2f-l 
UR2fSrO 
LDf2»TESTN0 
AIi2f2»Kl 
UR2f fTESTNO 
AD2»2»TESTID 
OSBf  f TASKQU 
GSBf fRREST 
GSB»  rRSTINT 
JT»f DISPAT 

/ 

Figure  36.  Test  Inter 


JSAUE  REGISTERS 
; BLANK  OUT 
J DISPLAY 

JGET  TEST  NUMBER 
> INCREMENT 
JSTORE 

?ADD  ID  NUMBER  OF  FIRST  TEST 
» QUEUE  UP  TEST 
^RESTORE  REGISTERS 
J RESET  INTERRUPT 
JGO  TO  DISPATCHER 


upt  Routine  (TESINT) 


Figure  37.  TESINT  Flowchart 


/  TEMPORARILY  CHANGE  INTERRUPT  PRIORITY  MASK 


/  ENTER  WITH  NEW  LEVEL  IN  L2 
/  BOTH  LI  AND  L2  ARE  USED 
PRICHG  NOP 

DCIf31»l 

LD»1»INTPRI 

URlIf31fO 

WR2»3rINTPRI 

RTN 


JMAKE  ROOM  ON  STACK 
>GET  INTERRUPT  PRIORITY  LEVEL 
JSAVE  ON  STACK 
JSET  NEW  LEVEL 


/ 

/  RESTORE  INTERRUPT  PRIORITY  LEVEL 
/  LATCH  1  IS  USED 

PRIRES  LDlI»31fO  JGET  OLD  LEVEL  FROM  STACK 

WR1»3»INTPRI  JRESTORE  IT  TO  INTPRI  AND  MASK 

DCI»31»-1  JCLEAR  STACK 

RTN 


/  RESET  INTERRUPT  REQUEST  AND  RETURN  TO  CALLING  PROGRAM 

WITHOUT  RETURNING  TO  INTERRUPTED  PROGRAM 
RSTINT  RTNINT  »RESET  INTERRUPT  REQUEST 

/ 

- - 


Figure  38,  PRICHG,  PRIRES  and  RSTINT  Routines 


*SET  3072 

/ 

/  LINK  TABLE  TO  JUMP  THROUGH  WHEN  CALLING  EXECUTIVE 


JT’f 

f INITI 

JT» 

fTASKQU 

JTf 

fDISPAT 

JTf 

f  DBSUPR 

JTf 

f IBUSSU 

JTf 

f IDTABL 

JTf 

fCLKTAB 

JTf 

fCLKREM 

JTf 

fPRICHG 

JTf 

f PR IRES 

/  INTERRUPT  VECTORS 

♦SET  3578 

JTfrTESINT 
JT»  rCLKINT 
JTfflBUSIN 
JTf rIBUSIN 
JTf »DBERR 
JTr  fDBCOMP 
END  NOP 


Figure  39.  Linkage  Tables 
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SECTION  III 


CENTRAL  INERTIAL  GUIDANCE  TEST  FACILITY  OPERATION 


This  section  defines  the  digital  processing  system  and  the  associated 
software  which  is  to  be  evaluated  at  the  CIGTF,  Holloman  Air  Force  Base. 
The  elements  of  the  digital  processing  system  are  shown  in  Figure  40.  The 
Hughes  digital  processor  is  a  breadboard  unit  designated  DPI  by  the  Air 
Force  Armament  Laboratory  (AFATL/DLMM),  Eglin  Air  Force  Base, 
Florida.  The  IMU  is  a  Hamilton  Standard  3030  breadboard  strapdown  iner¬ 
tial  measurement  unit  (GFE).  The  interconnection  of  these  elements  is  per¬ 
formed  by  the  weapon  bus,  the  bus  interface  units  (BIU's),  and  appropriate 
interface  equipment  developed  by  the  contractor. 

This  equipment  mechanizes  a  strapdown  inertial  navigation  system  in 
which  the  DPI  performs  the  required  computational  and  communication  func¬ 
tions  under  software  control.  The  performance  of  the  system  is  to  be  evalu¬ 
ated  on  the  basis  of  navigation  accuracy  relative  to  the  Completely  Integrated 
Reference  Instrumentation  System  (CIRIS).  CIRIS  performs  as  a  master 
navigator  and  records  DP  system  parameters  for  these  tests, 

SYSTEM  DESCRIPTION 

This  section  defines  the  system  functions  to  be  performed  and  the 
allocation  of  these  functions  among  the  system  elements.  The  system  hard¬ 
ware  is  described,  and  performance  parameters  are  summarized  in  the  sub¬ 
sequent  HARDWARE  DESCRIPTION  subsection.  The  interfacing  of  the 
system  software  with  the  system  hardware  is  performed  by  the  Executive 
software  described  in  Section  II.  The  system  software  functions  are  con¬ 
tained  in  a  number  of  software  tasks.  The  functions  performed  in  each  task 
and  the  interrelationships  of  the  tasks  are  presented  in  the  SOFTWARE 
DESCRIPTION  subsection.  The  detailed  software  documentation  is  presented 
in  the  Digital  Processor  Software  Development  Report,  Report  No.  DGWT 
0165-1. 

Functional  Description 

The  elements  of  the  system  configuration  to  be  evaluated  at  CIGTF 
are  shown  in  Figure  40.  The  functions  of  the  CIRIS  are  to(l)  supply  refer¬ 
ence  data  to  the  DPI  and (2)  request  and  format  DPI  data  for  the  instrumenta¬ 
tion  system.  The  system-level  timing  of  both  of  these  data  transfers  is 
controlled  by  the  HP2100  computer  in  CIRIS.  The  strapdown  IMU  supplies 
incremental  velocity  and  rotation  angle  data  to  DPI  in  a  coordinate  system 
determined  by  the  IMU  mounting  position.  The  timing  of  IMU  data  transfers 
is  controlled  by  DPI.  The  data  from  the  altimeter  (GFE)  is  used  for 
stabilization  of  the  vertical  channel  of  a  strapdown  inertial  reference  sys¬ 
tem.  The  timing  of  altimeter  data  transfer  to  DPI  is  controlled  by  DPI. 


HP2100 

INTERFACE 


REFERENCE/  INSTRUMENTATION 
(CIRIS) 


Figure  40.  Digital  Processing  System  (CIGTF)  Block  Diagram 


The  weapon  bus  and  BIU  elements  are  used  for  all  data  transfers 
within  the  system.  The  synchronization  of  the  system  operations  is  accom¬ 
plished  by  interrupt  messages  which  are  transmitted  on  the  interrupt  bus 
portion  of  the  weapon  bus. 

All  DPI  software  operations  are  initiated  either  by  operator  action 
using  the  control  panel  or  by  interrupts.  The  control  panel  provides  means 
for  the  operator  to  start  and  stop  DPI,  control  system  modes,  and  monitor 
system  operation  in  real  time.  When  the  START  button  is  pressed,  the  state 
of  the  DPI  is  initialized  in  preparation  for  receiving  reference  data  from  the 
HP2100  interface.  Only  self -test  software  execution  can  be  performed 
after  this  time  if  the  HP2100  is  not  connected  (or  simulated)  to  the  system. 

When  the  HP2100  is  supplying  reference  data,  the  available  system 
modes  are  set  by  the  control  panel  switches  for  either  free  navigation  or 
alignment.  The  first  set  of  reference  data  received  after  navigation  is 
enabled  will  cause  the  initialization  of  the  strapdown  inertial  navigation  soft¬ 
ware  to  the  state  corresponding  to  the  reference  data.  Data  transfers  from 
the  IMU  at  100  Hz  and  from  the  altimeter  at  10  Hz  are  also  initiated  under 
DPI  software  control  in  response  to  internal  DPI  time  strobe  interrupts. 

The  appropriate  strapdown  navigation  software  routines  will  be  performed 
at  the  corresponding  iteration  rates  until  the  RESET  button  on  the  control 
panel  is  pressed. 


The  alignment  filter  software  is  executed  once  for  each  set  of  refer¬ 
ence  data  received  after  alignment  is  enabled.  The  total  number  of  alignment 
filter  iterations  is  900  and  is  under  softwai  e  control.  After  this  nurhber  of 
iterations,  the  system  reverts  to  free  navigation. 


Instrumentation  data  is  transferred  from  the  DPI  to  the  HP2100  com¬ 
puter  when  requested  by  the  HP2100.  The  first  13  of  the  64  data  words  are 


a  repetition  of  the  last  set  of  reference  data  received  from  HP2100  by  the 
DPI.  Whenever  the  DPI  is  running  and  the  HP2100  is  operating,  the  ref¬ 
erence  data  may  be  compared  to  the  appropriate  instrumentation  data  block 
to  confirm  interface  integrity.  The  remaining  51  instrumentation  data 
words  allow  evaluation  of  the  strapdown  inertial  reference  performance. 


Hardware  Description 


Two  categories  of  hardware  elements  are  included  in  the  CIGTF 
Operation:  Government  Furnished  Equipment  (GFE)  and  Hughes  equipment 
developed  on  this  contract.  The  GFE  consists  of  the  Hamilton  Standard 
3030  breadboard  inertial  measurement  unit  (IMU),  the  altimeter,  and  the 
CIRIS.  The  Hughes -developed  equipment  includes  a  breadboard  digital 
processor  (DPI),  a  control  panel  for  the  processor,  the  weapon  bus,  equip¬ 
ment  to  interface  the  GPE  with  the  weapon  bus,  and  the  power  distribution 
and  power  supplies.  The  Hughes-developed  equipment  and  the  IMU  are 
installed  in  bays  3  and  4  of  a  palletized  rack,  as  shown  in  Figure  41.  The 
HP2100  computer  (part  of  CIRIS)  is  located  in  the  same  rack.  The 
remainder  of  the  CIRIS  is  installed  on  a  different  pallet.  The  altimeter  is 
also  remotely  located.  The  following  paragraphs  describe  the  hardware 
elements  and  show  their  performance  characteristics. 
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HS-3030  Inertial  Measurement  Unit.  The  HS-3030  strapdown  inertial 
measurement  unit  was  developed  for  aircraft  and  missile  applications 
requiring  moderate  inertial  quality  navigation  performance  in  the  range  of 
4  to  10  nmi/hour  CEP. 

9 

The  HS-3030  IMU  consists  of  an  orthogonal  triad  of  three  pulse  rebal¬ 
anced  Mini-Rig  30  strapdown  rate  integrating’ gyros,  three  pu^se  rebalanced 
Systron-Donner  484  accelerometers,  modul'ar  supporting  Digital  Control 
E’sctronics  (i.  e.  ,  countdown,  waveform  generation, and  input/output  inter¬ 
face  circuits),  and  a  sensor  block  temperature  dontroller  and  power  supply. 

The  three  HS-3030  gyro  loops  are  scaled  to  provide  a  full-scale  rate 
capability  of  +200  degrees/second  independently  about  each  of  the  three 
vehicle  primary  axes.  This  full-scale  capability  is  sufficient  to  accommo¬ 
date  the  most  severe  measuring  range  requirements  currently  anticipated 
tor  the  system.  In  order  to  provide  ooth  high  rate  and  precision  readout 
capabilities  while  at  the  same  time  conserving  system  operating  power,  a 
dual  gyro  measuring  rarge  capability  is  provided  for  each  of  the  three  gyro 
j^ebalance  channels.  Full-scale  rate  capability  in  the  low  rate  mode  is  iZ5 
negrees/second.  Mode  switching  is  accomplished  automatically  within  each 
servo  rebalance  electronics  channel.  Each  of  the  three  accelerometer  chan¬ 
nels  is  scaled  for  i40  g  full-scale  operation. 

Inertial  performance  characteristics  are  presented  in  Table  1, 


TABLE  1.  HS-3030  INERTIAL  MEASUREMENT 

SYSTEM  CHARACTERISTICS 
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CIRIS  Description.  The  Completely  Integrated  Reference  Instrumentation 
System  (CIRIS)  shown  in  Figure  42  is  capable  of  providing  highly  accurate 
position,  velocity  and  attitude  reference  over  long  flight  paths  fur  real-time 
use  in  testing  guidance  and  navigation  systems.  The  CIRIS  is  palletized  and 
normally  occupies  pallet  station  No.  1  in  the  C-141.  This  airborne  automated 
system  is  operationally  independent  due  to  integration  of  all  its  reference 
measurement  sources  by  minicomputers. 

CIRIS  generates  the  reference  data  by  using  four  measurement 
devices  that  are  controlled  and  time-coordinated  by  a  minicomputer  to  pro¬ 
vide  inputs  to  a  15-state  Kalman  filter.  The  real-time  filtered  reference 
data  which  is  generated  in  a  second  minicomputer  is  distributed  to  the  test 
data  acquisition  computer  and  recorded  with  the  raw  measurement  data  on 
the  magnetic  tape.  Further  processing  (backward  filtering  and  smoothing) 
can  be  done  postflight  as  required. 

The  measurement  hardware  includes  an  inertial  navigation  system 
stabilized  by  barometric  altitude  from  an  Air  Data  Computer,  a  Doppler 
Radar,  and  a  precision  radio  range/range-rate  system.  The  inertial  sys¬ 
tem  data  is  used  in  the  filter  as  a  continuous  reference  for  data  propagation 
and  reference  for  the  filter  error  states.  The  error  states  are  updated  by 
incorporation  of  barometric  altitude,  doppler  velocities,  and  precision  range 
and  range-rates  to  precisely  surveyed  ground  sites.  The  CIRIS  accuracies 
are  directly  dependent  on  the  measurements  obtained  from  the  range/range- 
rate  system  which  includes  an  airborne  interrogator  that  is  used  to  selec¬ 
tively  interrogate  one  ground-base  transponder  every  two  seconds,  A  set  of 
four  transponders  nearest  the  current  aircraft  location  is  used  to  provide 
one  recundant  measurement  in  a  time-phased  triangulation  scheme.  The 
transponders  and  associated  omnidirectional  antenna  are  portable  and  are 
designed  for  remote  operation.  They  are  deployed  in  a  triangular  pattern 
separated  by  approximately  150  miles  in  a  line  along  the  flight  path,  CIRIS 
degradation  can  occur  when  flight  paths  leave  areas  of  radio  range  coverage 
which  extends  to  200  nautical  miles  line-of- sight.  Incorporation  of  doppler 
radar  data  will  minimize  degradation  until  coverage  is  resumed. 

CIRIS  data  has  the  following  specifications: 

1,  Position  accuracy  to  13  feet  (1  sigma)  in  three  axes. 

2,  Velocity  accuracy  to  0.  10  ft/sec  (1  sigma)  in  three  axes. 

3,  Attitude  accuracy  to  3  arc -minutes  (1  sigma). 

4,  Real-time  reference  points  every  5  seconds. 

5,  Postflight  reference  points  every  2-4  seconds. 

Altimeter  Description.  The  altimeter  is  an  HLT  Industries,  Inc.  No. 
502000-39  Indicated  Altitude  Pressure  Transducer  System,  The  altimeter 
output  is  provided  by  a  potentiometer  whose  resistance  ratio  is  a  function  of 
altitude.  In  the  system,  the  potentiometer  is  supplied  with  a  reference 


voltage  from  the  IMU  interface,  and  the  pickoff  voltage  relative  to  the 
reference  voltage  provides  a  measure  of  altitude  to  the  IMU  interface.  The 
performance  characteristics  of  the  altimeter  are: 


Altitude  Range:  0  -  80000  feet 

Output  Linearity:  il%  of  full  range 

Nominal  Altitude  Resolution:  20  feet 

Repeatability  Error:  i60  1130  feet  (altitude  dependent) 

Hughes  Developed  Equipment.  A  detailed  description  of  the  Hughes  devel¬ 
oped  equipment  is  presented  in  Operating  Manual  and  System  Description  for 
Digital  Processor  Number  1  and  Installation  at  Central  Inertial  Guidance 
Test  Facility,  DGWT  0210-1.  This  section  provides  only  a  summary  of  the 
equipment  characteristics. 

Digital  Processor.  The  DPI  is  a  breadboard  implementation  of  a  subset  of 
the  digital  processor  architecture  presented  in  Volume  I  of  this  report. 

The  design  is  an  outgrowth  of  the  PDAP  design  and  incorporates  some 
instruction  set  modifications  to  facilitate  execution  of  digital  processor  soft¬ 
ware  functions.  The  DPI  instruction  set  is  presented  in  the  Programmers 
Manual,  DGWT  0170-2. 

The  DPI  breadboard  processor  consists  of  a  number  of  circuit  boards 
each  of  which  contains  an  autonomous  function  as  shown  in  Figure  43.  The 
circuit  boards  are  interconnected  by  a  common  bus  structure  allowing  the 
relative  position  of  the  boards  in  the  rack  to  be  changed  with  no  wiring 
changes.  Additional  boards;  e.g.  ,  program  memory,  may  also  be  plugged 
into  the  bus  structure. 

The  program  memory  (PM)  contains  the  machine  language  instruc¬ 
tions.  Three  PM  cards  were  fabricated:  one  read-only-memory  (ROM)  card 
for  flight  test,  and  two  read/write  (RAM)  cards  for  laboratory  tests.  The 
operand  memory  (OM)  card  contains  the  read/write  memory  for  storing  sys¬ 
tem  computational  variables.  A  block  of  ROM  for  storage  of  system  con¬ 
stants  were  installed  on  the  ROM  PM  card. 

The  control  unit  (CU)  card  decodes  the  instructions  from  the  PM, 
generates  timing  and  control  signals  for  the  processor,  and  generates 
addresses  for  both  the  OM  and  PM  cards.  The  arithmetic  unit  (AU)  card 
performs  arithmetic  and  logic  operations  on  operands.  The  interrupt  card 
UnT)  processes  interrupts  from  the  BIU  I/O  card  to  synchronize  the  proc¬ 
essor  operations  with  external  events.  The  BIU  I/O  interfaces  the  proc¬ 
essor  with  the  weapon  bus  and  provides  both  the  processor  clock  and  real 
time  clock  interrupts  (rate  set  under  software  control). 

The  DPI  parameters  are  shown  in  Table  2. 
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TABLE  2.  DPI  PARAMETERS 


NUMBER  OF  INSTRUCTIONS: 

COMPUTATION  WORD  LENGTH: 

PROCESSOR  THROUGHPUT  (SPECIFICATION  MIX): 
PROGRAM  MEMORY 

PROGRAM  WORD  SIZE 

TECHNOLOGY:  ROM  OR  RAM  -  SELECTABLE  IN 

1  K  WORD  BLOCKS  VIA  SWITCHES  ON 
PM  CAROS. 

OPERAND  MEMORY:  RAM 

ROM 

TOTAL  ADDRESS  SPACE  (INCLUDING  I/O) 

VECTORED  PRIORITY  INTERRUPTS: 

SUBROUTINE  STACK: 

INDEX  REGISTERS: 

ARITHMETIC  REGISTERS: 

FLAGS: 


64 

16  BITS 
1.85  MOPS 
4  K  WORDS 

24  BITS 

2  K  WORDS 
512  WORDS 
4  K  WORDS 
15  LEVELS 
32  LEVELS 
2 
2 
64 


Control  Panel.  The  Control  Panel  (Figure  44)  is  used  for  both  monitoring 
and  controlling  the  DPI. 

Information  from  Program  Memory,  the  24-bit  instruction  word,  is 
displayed  on  the  top  octal  display  and  is  broken  down  into  the  OP  code,  the 
Tag  Field,  and  the  Address  Field,  left  to  right,  respectively. 

The  1 6-bit  Data  Bus  is  displayed  in  the  next  octal  display  and  also 
can  be  selected  for  decimal  display  by  the  rotary  select  switch. 

By  software  control,  the  information  on  the  Data  Bus  can  be  latched 
into  the  next  octal  display.  The  programmer  has  this  feature  at  his  control 
by  inserting  the  instruction  to  output  data  to  I/O  Latch  5.  The  information 
can  be  displayed  in  decimal  through  the  decimal  display  switch. 

The  Data  Bus  can  also  be  latched  for  octal  and  decimal  display,  using 
the  Operand  Memory  (OM)  or  Program  Memory  (PM)  Address.  By  selection 
of  a  desired  address  on  the  octal  thumbwheel  switch  labeled  OM/PM  ADDR 
FOR  DB  LATCH,  then  choosing  either  OM  or  PM  on  the  toggle  switch,  the 
contents  of  the  Data  Bus  will  be  latched  into  the  DB  LATCH  (PM/OM  ADDR) 
display  when  the  OM  ADDRESS  or  PM  ADDRESS  selected  in  the  thiunbwheel 
switch  is  reached  in  the  program.  This  will  be  a  continuirg  update  as  long 
as  the  program  is  run. 
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The  program  can  be  stopped  by  several  means.  The  simplest  is  to 
depress  the  STOP  pushbutton  which  will  halt  the  DPI  at  its  present  address. 
Pressing  the  START  button  will  continue  the  program  from  that  address.  If 
RESET  is  pressed,  the  program  vdll  stop  and  the  program  counter  will  be 
set  to  zero  where  the  program  will  continue  from  when  restarted.  Pressing 
STEP  will  also  stop  the  program,  similar  to  STOP,  and  continual  depress¬ 
ing  will  continue  the  program  from  that  point, one  instruction  at  a  time. 

The  PM  ADDRESS  FOR  STOP  octal  thumbwheel  .switch  can  be  used 
for  stopping  the  DPI  when  the  STOP  toggle  switch  is  set  to  enable.  When  the 
program  reaches  the  thumbwheel  PM  address,  it  will  stop.  Pressing 
START,  the  program  will  continue  on  from  that  point. 

Both  the  OM  and  PM  address  are  displayed  in  octal  continuously  and 
in  addition  can  be  selected  for  display  as  a  decimal  number.  The  PM  ADDR 
FOR  STOP  OCTAL  thumbwheel  can  be  selected  for  decimal  display  to  assist 
perhaps  in  any  octal  to  decimal  conversion  calculation. 

The  Flag  Word  Group  3  switches  are  used  under  software  recognition, 
usually  as  conditions  for  branching. 

The  Test- Interrupt  is  used  when  all  other  interrupts  (such  as  the 
B,  I,  U.  -I/O)  are  electrically  disconnected  from  the  DPI  and  is  purely  for 
test  and  troubleshooting.  To  enable  any  of  the  15  priority  interrupts,  the  15 
rocker  DIP  switches  on  the  Test  Panel  Card  have  to  be  switched  accordingly. 
Then  the  Test-Interrupt  pushbutton  will  enable  the  selected  interrupt  to  the 
DPI. 

Weapon  Bus.  The  weapon  bus  provides  a  communication  link  for  the  transfer 
of  ^ata  and  control  signals  between  the  system  elements.  All  communication 
over  the  weapon  bus  is  in  bit  serial  format.  Separate  communication  paths 
are  provided  for  data  (weapon  data  bus)  and  control  signals  (weapon  interrupt 
bus).  All  data  transfers  are  under  the  control  of  the  DPI  software  via  the 
master  bus  interface  unit  connected  to  DPI.  Control  signal  transfers  may  be 
initiated  by  any  system  element  by  sending  the  appropriate  commands  to  the 
slave  BIU  which  connects  it  to  the  bus.  Control  signals  are  transferred  as 
an  8  bit  interrupt  identifier.  The  BIU's  only  provide  an  interface  between  the 
weapon  bus  and  the  system  elements  --  all  interpretation  of  command  mes¬ 
sages  or  data  is  performed  by  the  respective  interface  equipment  (IMU  or 
HP2100)  as  discussed  in  the  next  section.  The  performance  parameters  of 
the  weapon  bus  are  summarized  in  Table  3. 

HP2100  Interface.  The  HP2100  Interface  equipment  interfaces  the  HP2100 
computer  (CIRIS)  with  its  BIU,  The  HP2100  supplies  reference  data  to  the 
interface  as  a  block  of  13  words  (16  bit  data  content  per  word)  in 
CAROUSEL  IV  format.  These  words  are  stored  in  a  buffer  memory  in  the 
interface  in  preparation  for  transmission  to  the  DPI  via  the  weapon  data 
bus.  Two  interrupt  messages  are  sent  to  DPI  concerning  the  reference  data 
by  the  interface.  A  time  Sync  interrupt  (ID  =  1)  notifies  the  DPI  that  the 
first  word  of  the  reference  data  block  has  been  received  and  acts  as  a 
marker  to  indicate  the  time  at  which  the  reference  data  was  generated  by 
CIRIS.  A  Reference  Data  Ready  interrupt  (ID  =  2)  is  seht  to  the  DPI  when 
all  13  words  have  been  stored  in  the  buffer. 
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When  the  HP2100  desires  instrumentation  data  from  DPI,  an  Instru¬ 
mentation  Data  Request  discrete  is  sent  to  the  interface  which  sends  the  cor¬ 
responding  interrupt  (ID  =  5)  to  DPI.  As  the  instrumentation  data  is 
received  from  DPI  via  the  weapon  data  bus,  it  is  transferred  in  word  serial 
format  to  the  HP2100  at  the  data  bus  word  transfer  rate,  A  data  valid  strobe 
is  also  output  to  the  HP2100  by  the  interface  for  each  word. 


TABLE  3.  WEAPON  BUS  PARAMETERS 


WEAPON  DATA  BUS 

DATA  CONTENT/WORD 

16  BITS 

MAXIMUM  DATA  BLOCK  SIZE 

256  WORDS 

TRANSMISSION  RATE  CAPACITY 

100K  WORDS/SECOND 

WEAPON  INTERRUPT  BUS 

INTERRUPT  IDENTIFIER 

8  BITS 

SINGLE  WORD  TRANSMISSION 

TRANSMISSION  RATE  CAPACITY 

120K  WORDS/SECOND 

IMU  Interface.  The  IMU  interface  connects  both  the  IMU  and  the  altimeter 
to  the  BIU,  Data  is  requested  of  the  IMU  by  the  interface  when  it  receives 
either  the  Data  Request  interrupt  (ID  =  64)  from  the  DPI  via  the  weapon 
interrupt  bus.  Either  of  these  interrupts  will  cause  the  IMU  REQ  signal  to 
be  sent  to  the  IMU  which  responds  with  the  IMU  DR  signal  when  the  first  of 
the  six  IMU  parameters  is  ready  at  its  output.  The  interface  sends  the  Data 
Ready  (IMU)  interrupt  (ID  =  8)  to  DPI  at  the  time.  The  DPI  then  accesses 
the  IMU  data  via  the  weapon  data  bus.  The  six  IMU  parameters  are  trans¬ 
ferred  from  the  IMU  through  the  interface  to  BIU  in  word  serial  format  at 
the  data  bus  transmission  rate.  The  receipt  of  the  Test  Data  Interrupt  also 
causes  a  Test  discrete  to  be  output  by  the  interface,  but  the  test  function  is 
not  available  in  the  breadboard  IMU. 

When  the  Start  Conversion  interrupt  (ID  =  32)  is  received  by  the  inter¬ 
face  from  DPI,  the  altimeter  output  analog  signal  is  converted  to  digital  for¬ 
mat  and  stored  in  a  buffer.  When  the  digital  word  is  stored,  the  interface 
outputs  a  Conversion  Complete  interrupt  (ID  =  10)  to  DPI  which  may  then 
initiate  the  transfer  of  the  altimeter  data  via  the  weapon  data  bus. 

Software  Description 

The  DPI  software  consists  of  25  modules  (tasks)  which  perform  five 
system  functions;  System  Management,  Navigation,  Alignment,  Instrumen¬ 
tation,  and  Self-Test,  Any  discussion  of  these  software  functions  must  also 
include  the  operations  occurring  in  the  system  hardware  elements  and  the 
operations  of  the  executive  software  which  interfaces  the  functional  software 
with  the  hardware.  The  function  of  the  system  is  to  implement  a  strapdown 
inertial  navigator.  Within  this  system  function,  the  software  performs  the 
required  communication  control  and  computational  functions. 


The  operating  sequences  in  the  system  and  the  individual  software 
tasks  are  described  herein.  Detailed  documentation  of  these  software  mod¬ 
ules  is  presented  in  the  Digital  Processor  Software  Development  Report, 

No.  DGWT  0165-1. 

System  Operating  Sequences.  All  operating  sequences  are  initiated  by  hard¬ 
ware  interrupts.  The  selection  of  computational  processes  is  performed  by 
the  appropriate  System  Management  software  module  (task)  under  control  by 
the  operator  via  the  control  panel  switches.  The  system  operating  procedur. 
is  presented  in  DGWT  0220-1  and  will  not  be  repeated  in  this  section.  The 
following  paragraphs  are  concerned  with  the  processing  of  system  interrupts 
and  system  data  after  the  appropriate  system  power-on  and  initialization 
procedure. 

Reference  Data  Interrupt  Sequences.  Two  system  interrupts  are  gen¬ 
erated  by  the  ^1^2 100  interface  in  response  to  reference  data  inputs  by  the 
HP2100  computer.  This  TIME  SYNC  interrupt  (ID  =  1)  (see  Figure  45)  is 
generated  and  sent  to  DPI  when  the  first  reference  data  word  is  received. 

The  executive  module,  IBUSIN,  is  called  when  the  interrupt  is  received  by 
DPI  and  queues  up  Task  1  (TSINT)  for  execution.  This  System  Management 
task  enables  the  processing  of  the  Reference  Data  Ready  interrupt,  sets  an 
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Figure  45,  Time  Sync  Interrupt  Sequence 


ALIGN  flag  according  to  the  position  of  the  control  panel  ALIGN  switch,  and 
calls  the  TASKQU  (Executive  module)  to  queue  up  Task  23  (TSYNC),  The 
alignment  module,  TSYNC,  transfers  DPI  navigation  data  for  use  by  the 
alignment  filter. 

The  Reference  Data  Ready  interrupt  (ID  =  2)  processing  is  shown  in 
Figure  46.  The  receipt  of  the  interrupt  by  DPI  causes  the  IBUSIN  module 
to  queue  the  REFRED  (System  Management  task)  for  execution.  REFRED 
calls  the  DBSUPR  executive  module  with  the  appropriate  data  bus  message 
parameters.  DBSUPR  initiates  the  transfer  of  the  reference  data  from  the 
HP2100  interface  to  DPI  via  the  weapon  data  bus.  Completion  of  the  trans¬ 
fer  generates  the  XFER  COMPLETE  interrupt  which  calls  the  DBCOMP 
executive  module.  DBCOMP  queues  the  RDXFRD  system  management  task 
which  initiates  processing  of  the  reference  data.  The  first  operation  of 
RDXFRD  is  to  qu^-ue  the  RINIT  system  management  task  via  a  call  to  the 
executive  TASKQU  module.  RINIT  transfers  the  reference  data  to  the  DPI 
operand  memory  and  performs  format  conversions  required  for  compati¬ 
bility  with  the  DPI  computational  modules.  Further  processing  of  the  ref¬ 
erence  data  is  controlled  by  the  RDXFRD  module. 

Navigation  Initialization  and  Initiation  (Figure  47).  The  navigation 
computation  state  of  DPI  is  initialized  to  correspond  to  the  first  set  of 
reference  data  received  after  the  control  panel  navigation  switch  is  on.  The 
initialization  operation  is  controlled  by  RDXFRD  which  queues  up  IMUINT 
via  a  call  to  the  executive  TASKQU  module.  RDXFRD  also  inserts  the 
IlOO-Hz  task  in  the  clock  table  to  be  called  by  the  executive  at  a  100-Hz  rate. 

IMU  Data  Formatting  and  Data  Transfer  (Figure  48).  The  executive 
CLKINT  module  is  called  at  a  400-Hz  rate  and,  in  turn,  queues  up  the 
IlOO-Hz  task  for  execution  at  100  Hz,  1100  Hz  calls  the  executive  IBUSSU 
module  which  sends  the  IMU  DATA  REQUEST  interrupt  (ID  =  128)  to  the 
IMU  interface  via  the  weapon  interrupt  bus.  When  the  IMU  data  is  formatted 
and  ready  for  transfer,  the  IMU  interface  sends  the  DATA  READY  interrupt 
(ID  =  8)  to  DPI.  Receipt  of  this  interrupt  calls  the  IBUSIN  executive  module 
which  queues  the  DATRED  system  management  task.  DATRED  calls  the 
DBSUPR  executive  module  with  the  appropriate  data  message  parameters. 
DBSUPR  then  initiates  the  transfer  of  IMU  data  to  the  DPI  via  the  weapon 
data  bus.  The  completion  of  the  data  transfer  generates  the  XFER  COM¬ 
PLETE  interrupt  which  calls  the  DBCOMP  executive  module,  DBCOMP 
queues  the  IMUCOM  system  management  task  which  checks  the  validity  of 
the  IMU  data  and  transfers  it  to  the  DPI  operand  memory. 

Navigation  Computations  (Figure  49).  The  navigation  computations 
are  initiated  by  the  IMUCOM  task  which  queues  up  the  IMUlOO  task  via  a  call 
to  the  executive  TASKQU  module.  The  IMUlOO  updates  the  navigator  state 
using  the  IMU  data  at  a  lOO-Hz  rate  and  also  performs  high  priority  compu¬ 
tations  at  a  100-Hz  rate.  Lower  priority  computations  at  10-Hz  and  1-Hz 
rates  are  initiated  by  this  module.  The  altimeter  data  sequence  (see  Fig¬ 
ure  50)  is  performed  at  a  10-Hz  rate.  The  1-Hz  computations  are  initiated 
via  a  call  to  the  executive  TASKQU  module  which  queues  up  the  IMUl  task. 


J 


Figure  46.  Reference  Data  Ready  Interrupt  Processing 
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Figure  47.  Navigation  Initialization  and  Initiation 
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Figure  48,  IMU  Data  Formatting  and  Transfer 
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Figure  49.  Navigation  Comoutations 
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Altimeter  Data  Sequence  (Figure  50).  The  altimeter  data  sequence 
is  initiated  by  the  IMUlOO  which  calls  the  executive  IBUSSU  module  at  a 
IO-H7,  rate.  The  IBUSSU  sends  the  START  CONVERSION  interrupt  (ID  :=  32) 
to  the  IMU  interface.  The  IMU  interface  converts  the  altimeter  signal  to 
digital  format  and  sends  the  CONVERSION  COMPLETE  interrupt  (ID  =  10) 
to  DPI.  This  interrupt  calls  the  executive  IBUSIN  module  which  queues  the 
ALTRED  module.  ALTRED  calls  the  DBSUPR  module  with  the  altimeter 
message  transfer  parameters  and  DBSUPR  initiates  the  transfer.  The  XFER 
COMPLETE  interrupt  calls  the  executive  DBCOMP  module  which  queues  the 
navigation  IMU  10  task. 

Alignment  Initialization  and  Computations  (Figure  51).  A  sequencer 
associated  with  the  alignment  function  is  controlled  by  the  RDXP'RD  system 
management  module.  The  first  execution  of  this  module  (see  Figure  46) 
after  the  ALIGN  flag  is  ON  (set  Ijy  TSINT  module)  will  initialize  the  align¬ 
ment  filter.  Initialization  is  performed  by  the  FINI  module  which  is  queued 
via  a  call  to  the  executive  TASKQU  module.  As  a  part  of  the  alignment  initial¬ 
ization,  the  lOO-Hz  alignment  task  (CENTSK)  is  connected  to  the  clock  inter¬ 
rupt.  Task  6  also  queues  the  alignment  filter  computation  task  (DRITSK.) 

900  times  via  a  call  to  the  executive  TASKQU  module  (CONTRL)  each  time  it 
is  executed.  When  the  alignment  filter  is  operating,  Task  6  also  queues  the 
gyro  bias  computation  module  (GYRO)  after  each  300  iterations  of  the  align¬ 
ment  filter. 

IMU  Data  Accumulation  (Figure  52).  The  IMU  data  accumulation 
module  (COMPT)  is  connected  to  the  clock  interrupt  as  part  of  the  DPI  ini¬ 
tialization  function. 

Instrumentation  Data  Transfer  Sequence  (Figure  53).  The  instrumen¬ 
tation  data  transfer  sequence  is  initiated  by  the  HP2100  interface  when  it 
receives  the  instrumentation  request  from  the  2100.  The  interface  sends  the 
INSTRUMENTATION  DATA  REQUEST  interrupt  (ID  =  5)  to  DPI.  This  inter¬ 
rupt  calls  the  IBUSIN  executive  module  which  queues  the  INSREQ  task.  This 
task  formats  the  instrumentation  data  in  preparation  for  transfer  and  then 
calls  the  DBSUPR  executive  module  with  the  data  message  parameters.  The 
DBSUPR  initiates  the  data  transfer.  No  software  task  is  queued  by  the 
DBCOMP  module  when  it  is  called  by  the  XFER  COMPLETE  interrupt. 

Self-Test  (Figure  54).  Three  self-test  software  tasks  are  sequenti¬ 
ally  called  by  pressing  the  control  panel  test  interrupt  as  shown  in  the  figure. 
The  sequencing  of  these  tasks  is  performed  by  the  executive  TEST  INTER¬ 
RUPT  handling  routine.  TESTDP  and  BIUTES  perform  tests  on  the  DPI  and 
weapon  bus  hardware  elements,  respectively.  CHKSU  is  a  sequencing  mod¬ 
ule  which  queues  a  test  data  generation  module,  SIMULT,  at  a  simulated 
100-Hz  rate  and  controls  the  sequencing  of  the  navigation  and  alignment 
computational  functions  at  the  corresponding  rates.  This  sequencing  module 
essentially  replaces  the  normal  system  interrupts  associated  with  IMU  and 
reference  data  generation  and  transfers  by  queueing  the  appropriate  modules 
under  software  control. 
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Figure  50.  Altimeter  Data  Sequence 
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Figure  53.  Instrumentation  Data  Transfer  Sequence 
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Software  Module  Description.  This  subsection  contains  a  brief  description 
of  each  of  the  software  modules  applicable  to  the  DPI  system.  The  execu¬ 
tive  software  is  discussed  in  subsection  2.  2  and  is  not  repeated  in  this  sub¬ 
section.  A  list  of  the  software  modules  by  task  ID  is  shown  in  Table  4.  In 
the  following  paragraphs,  the  software  module  descriptions  are  organized 
by  the  system  functions. 

System  Management.  Task  1  (TSINT)  is  queued  up  when  the  time  sync 
interrupt  is  received  from  the  HP2100.  This  occurs  at  a  1-Hz  rate.  This 
task  stores  the  100-Hz  counter  in  the  instrumentation  buffer  and  sets  a  flag 
(REF-DA TA-XFER)  to  indicate  that  a  block  of  reference  data  is  being  received 
from  the  2100,  It  also  examines  the  ALIGN  switch  on  the  control  panel  and 
sets  the  ALIGN  flag  if  the  switch  is  up.  This  task  queues  up  Task  23. 

Task  2  (REFRED)  is  queued  up  when  the  reference  data  ready  inter¬ 
rupt  is  received  from  the  HP2100.  This  occurs  at  a  1-Hz  rate  approximately 
50  ms  after  the  time  sync  interrupt  is  received.  If  the  REF-DATA-XFER 
flag  is  true  this  task  starts  the  transfer  of  the  reference  data  from  the  2100 
interface  unit  to  the  DP  via  the  data  bus.  The  completion  of  this  transfer 
will  queue  up  Task  6, 

Task  4  (IMUCOM)  is  queued  up  by  the  completion  of  the  IMU  data 
transfer  to  DPI.  This  task  checks  the  validity  of  the  IMU  data  just  received 
by  comparison  with  maximum  expected  data  magnitudes.  Valid  data  is  trans¬ 
ferred  to  the  appropriate  operand  memory  locations, and  invalid  data  is  dis¬ 
carded  (previous  valid  data  is  used).  This  task  then  queues  Task  9  (IMUlOO), 

Task  6  (RDXFRD)  is  queued  up  when  the  reference  data  from  the 
HP2100  has  been  transferred  to  the  DP.  This  transfer  is  started  by  Task  2 
and  occurs  at  a  1-Hz  rate.  This  task  queues  Task  15  to  transfer  the  ref¬ 
erence  data  to  the  appropriate  operand  memory  locations.  When  the  navi¬ 
gate  switch  on  the  control  panel  is  raised, this  task  starts  the  navigation 
routines  running  by  queueing  up  Task  14  once  and  connecting  Task  7  to  the 
clock  for  execution  at  a  100-Hz  rate.  When  the  align  switch  on  the  control 
panel  is  raised,  this  task  provides  the  sequencing  for  the  alignment  tasks  by 
queueing  up  Task  16  once,  connecting  Task  22  to  the  clock  for  execution  at 
a  100-Hz  rate,  queueing  up  Task  17,  900  times  at  a  1-Hz  rate,  and  queueing 
up  Task  18,  three  times  at  5-minute  intervals. 

Task  7  (1100  Hz)  is  queued  up  by  the  clock  at  a  100-Hz  rate.  It 
requests  data  from  the  IMU.  When  the  IMU  responds,  Task  8  will  be  queued 
up. 

Task  8  (DATRED)  is  queued  up  when  the  IMU  data  ready  interrupt  is 
receive.d  from  the  IMU  interface  at  a  lOO-Hz  rate.  This  task  starts  the 
transfer  of  data  from  the  IMU  to  the  DP  via  the  data  bus.  When  this  transfer 
is  complete,  Task  4  will  be  queued  up. 

Task  10  (ALTRED)  is  queued  up  when  the  altimeter  data  ready  inter¬ 
rupt  is  received  from  the  IMU  interface  at  a  10-Hz  rate.  This  task  starts 


TABLE  4.  SOFTWARE  MODULES 


ID 

TASK 

PRIORITY 

NAME 

1 

PROCESS  TIME  SYNC  FROM  2100 

8 

TSINT 

2 

TRANSFER  REFERENCE  DATA  TO  DP 

5 

REFRED 

4 

VALIDATE  IMU  DATA 

8 

IMUCOM 

5 

PROCESS  INSTRUMENTATION  DATA  REQUEST 

3 

INSREQ 

6 

PROCESS  REFERENCE  DATA 

5 

RDXFRD 

7 

REQUEST  IMU  SENSOR  DATA  AT  100  HZ 

8 

I100HZ 

8 

TRANSFER  IMU  DATA  TO  DP 

8 

DATRED 

9 

PROCESS  IMU  DATA 

8 

IMU100 

10 

TRANSFER  ALTIMETER  DATA  TO  DP 

6 

ALTRED 

11 

PROCESS  ALTIMETER  DATA 

6 

IMU10 

12 

UPDATE  SLOW  NAV  PARAMETERS  AT  1  HZ 

8 

IMU1 

13 

ACCUMULATE  IMU  DATA 

8 

COMPT 

14 

INITIALIZE  NAVIGATION  PARAMETERS 

6 

IMUINT 

15 

SCALE  REFERENCE  DATA 

6 

RINIT 

16 

INITIALIZE  ALIGNMENT  PARAMETERS 

6 

FINI 

17 

PERFORM  ALIGNMENT  ALGORITHM 

6 

DRITSK 

18 

PERFORM  GYRO  BIAS  CALCULATIONS 

6 

GYRO 

19 

20 

21 

UPDATE  ALIGNMENT  CONTROL  FEEDBACK 

8 

CONTRL 

22 

PERFORM  ALIGNMENT  FILTE R  PROCESSING  AT  100  HZ 

8 

CENTSK 

23 

STORE  ALIGNMENT  AND  NAV.  PARAMETERS  AT  TIME  STROBE 

8 

TSYNC 

24 

INITIALIZE  SELF  TEST  PARAMETERS 

6 

SIMINT 

25 

PERFORM  100  HZ  SELF  TEST  CALCULATIONS 

8 

SIMULT 

26 

27 

28 

29 

30 

31 

32 

TEST  DP  FUNCTIONAL  UNITS 

5 

TESTDP 

33 

TEST  BIU'S 

5 

BIUTES 

34 

TEST  NAVIGATION  AND  ALIGNMENT  EQUATIONS 

5 

CHKSU 
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the  transfer  at  altimeter  data  from  the  IMU  interface  to  the  DP  via  the  data 
bus.  When  this  transfer  is  complete,  Task  1  1  will  l^e  queued  up. 

Task  15  (RINIT)  is  queued  by  Task  6  to  transfer  the  reference  data  to 
the  appropriate  instrumentation  data  operand  memory  locations.  This  task 
also  formats,  rescales,  and  stores  the  reference  data  in  operand  memory 
for  use  by  the  navigation  and  alignment  software  modules. 

Navigation.  Task  9  (IMUlOO)  is  queued  up  by  Task  4  at  100  Hz  to 
process  the  IMU  data.  This  task  performs  the  IMU  data  compensation  cal¬ 
culations,  the  quaternion  (attitude)  update  calculations,  and  integrates  the 
accelerometer  data  in  the  navigation  frame  to  determine  velocity  and  posi¬ 
tion  at  a  100-Hz  rate.  Navigation  frame  rotations  are  performed  at  a  10-Hz 
rate.  The  altimeter  data  sequence  is  initiated  at  a  10-Hz  rate.  This  task 
also  queues  Task  12  at  a  1-Hz  rate. 

Task  11  (IMUIO)  is  queued  when  the  altimeter  data  has  been  trans¬ 
ferred  to  DPI  (10-Hz  rate).  This  task  performs  gravity  and  coriolis  com¬ 
pensation  computations  and  uses  the  altimeter  data  for  vertical  channel  damp¬ 
ing.  Latitude  and  longitude  parameters  are  updated  by  this  task. 

Task  12  (IMUl)  is  queued  by  Task  9  at  a  1 -Hz  rate.  This  task  com¬ 
putes  slowly  varying  navigation  parameters  which  are  used  in  Tasks  9  and  11, 

Task  14  (IMUINT)  is  queued  once  by  Task  6,  This  task  initializes  the 
attitude,  velocity,  and  position  navigation  parameters  to  correspond  to  the 
reference  data.  Navigation  software  parameters,  both  computational  and 
control,  are  also  initialized  to  the  appropriate  state  by  this  task. 

Alignment.  Task  16  (FINI)  is  queued  once  by  Task  6  at  the  first 
occurrence  of  the  REFERENCE  DATA  READY  interrupt  after  the  aligp  flag 
is  set.  (This  flag  is  raised  by  the  system  management  software  when  one  of 
the  DPI  front  panel  flag  switches,  Switch  No.  1,  is  set.  Thereafter,  the 
position  of  the  switch  has  no  effect.  )  FINI  initializes  the  Kalman  filter  soft¬ 
ware  parameters.  FINI  also  serves  one  additional  function:  prefilter  level¬ 
ing,  which  is  designed  to  reduce  the  initial  tilt  errors. 

Task  22  (CENTSK)  is  queued  by  the  clock  service  routine  and  contains 
all  of  the  100-Hz  filter  calculations.  The  sole  purpose  of  CENTSK.  is  to 
accumulate  north,  west,  and  vertical  velocity  increments  with  the  scaling 
FS  =  128  ft/sec.  These,  after  approximately  one  second's  accumulation, 
make  up  the  rapidly-varying  transition  matrix  elements.  Because  this  mod¬ 
ule  uses  a  vector  variable  which  is  updated  at  100  Hz  (by  a  navigation  rou¬ 
tine  with  priority  8),  CENTSK  must  have  priority  8. 

Task  23  (TSYNC)  is  initiated  by  Task  1  as  a  response  to  the  TIME 
SYNC  interrupt,  which  signals  the  start  of  the  reference  data  transfer.  This 
is  the  earliest  available  time  marker  for  the  reference  velocity  and  position 
values,  and  in  order  to  make  a  meaningful  comparison,  the  corresponding 
DP  navigation  parameters  should  be  sampled  at  this  time  and  put  into  safe 
storage.  Since  DP  navigation  software  calls  for  latitude /longitude  updates  at 


only  a  10-Hz  rate,  a  call  to  the  update  module  LTNG  is  made  at  this  time 
to  ensure  that  the  most  current  values  are  used.  (No  correction  is  made  for 
the  staleness  of  the  reference  data,  that  is,  for  the  Ijrief  passage  of  time 
between  the  generation  of  the  data  and  the  start  of  the  transfer  to  the  DP.  ) 
TSYNC  also  performs  two  other  functions:  (1)  transfers  the  accumulated 
velocity  increments  into  the  correct  transition  matrix  elements,  resetting  the 
accumulators  to  zero,  and  (2)  calculates  the  elapsed  time  since  the  last  ref¬ 
erence  data  transfer,  so  that  a  rather  large  variation  in  the  nominal  1-Hz 
transfer  rate  can  be  accommodated. 

Task  17  (DRITSK)  is  queued  by  Task  6  when  the  reference  data  set 
has  been  entirely  transferred  (all  information  needed  in  the  Kalman  filter 
update  has  been  assembled).  In  order  of  occurrence,  DRITSK.  does  the  fol¬ 
lowing  things;  (1)  Updates  the  slowly  varying  transition  matrix  elements, 
bypassing  some  of  these  when  velocity-match  only  is  selected.  (Note;  all 
of  the  rapidly  varying  elements  are  updated  in  the  module  TSYNC.  Also,  we 
actually  use  the  matrix  "D,  "  that  is,  the  transition  matrix  minus  the  7  by  7 
identity  matrix,  )  (2)  Updates  the  covariance  matrix  P  to  reflect  the  passage 
of  time  AT  since  the  last  measurement.  (3)  Symmetrizes  the  P  matrix  and 
adds  1  LSB  process  noise,  Q,  to  the  diagonal  elements.  (4)  Tests  for  scaling 
headroom  in  the  matrix  P  and  the  measurement  noise  covariance  matrix  R. 

If  these  can  be  shifted  up,  this  is  done,  recording  the  cumulative  shift  count 
in  the  variable  SCLCNT.  (5)  Calculates  position  and  velocity  errors,  scaling 
them  up  to  form  single  precision  measurement  vector  elements.  (6)  Perforins 
the  measurement  updates.  17)  Rescales  the  single-precision  state  estimates 
to  fqrm  the  appropriate  corrections  to  the  navigation  parameters.  (8)  Places 
CONTRL  in  the  task  queue  to  perform  the  corrections  at  the  necessary  higher 
priority.  (9)  Resets  the  state  estimates  to  zero  and  returns  control  to  the 
executive. 

Task  18  (GYRO)  is  queued  a  total  of  three  times:  at  the  300^^,  the 
600^^,  and  900^“  occurrence  of  the  REFERENCE  DATA  READY  interrupt 
after  the  ALIGN  mode  is  entered  (that  is,  after  5  minutes,  10  minutes,  and 
15  minutes  have  elapsed)  by  Task  6.  In  each  case,  the  cumulative  misalign¬ 
ment  estimates  are  reset  to  zero,  the  Kalman  filter  is  reinitialized,  and 
DRITSK.  is  called  as  a  subroutine.  On  the  second  and  the  third  entries,  how¬ 
ever,  GYRO  uses  the  accumulated  misalignment  estimates  to  estimate  gyro 
biases  and  compensate  for  them.  The  general  idea  behind  this  calculation  is 
that  the  misalignment  which  builds  up  during  these  periods  is  due  to  gyro 
drift;  i.  e.  , 

/3.  =  6.  +  (5  minutes) 

11 

where 

i  =  1,  2,  3. 

The  first  5-minute  period  is  disqualified  as  a  large  initial  misalignment 
may  be  present.  GYRO  also  has  the  relatively  low  priority  of  6. 

Task  21  (CONTRL)  is  queued  by  Task  17  at  high  priority  (level  8)  to 
correct  the  navigation  state.  The  first  correction  is  to  the  navigation 


quaternion  q,  in  whose  four  elements  all  attitude  information  resides.  Essen¬ 
tially  what  is  done  is  to  multiply  by  a  correction  quaternion,  which  is  close 
to  the  identify  (0,  0,  0,  1);  actually,  it  is  equal  to  (6i,  62*  ^  “  l/2<5i^  - 

1/2  62^  ■  1/263^  )  to  second  order  in  the  misalignment  angles  <5|,  62'  <53. 

More  precisely,  we  use  the  fact  that  the  correction  quaternion  has  the  form 
I  +A;  first  A  q  is  calculated,  and  the  result  added  (with  overflow  safeguards) 
to  q  to  form  the  corrected  attitude  quaternion.  The  next  part  of  the  control 
task  is  to  correct  the  latitude,  longitude,  north  velocity,  and  west  velocity 
variables  by  subtracting  from  these  (double-precision)  the  best  estimates  of 
their  errors. 

Instrumentation.  Task  5  (INSREQ)  is  queued  up  when  an  instrumen¬ 
tation  data  request  is  received  from  the  HP2100.  This  occurs  at  a  1-Hz  rate. 
This  task  calculates  the  cvirrent  position  and  velocity  errors  and  transfers 
them  along  with  the  rest  of  the  instrumentation  data  into  the  output  buffer. 

Then  it  starts  the  transfer  of  the  instrumentation  data  from  the  output  buffer 
to  the  HP2100  via  the  data  bus.  No  tasks  are  queued  up  at  the  completion  of 
this  transfer. 

Task  13  (COMPT)  is  queued  at  100  Hz  by  the  executive  clock  service 
routine.  When  navigation  is  enabled,  this  task  accumulates  raw  and  compen¬ 
sated  IMU  data  for  instrumentation.  This  task  also  provides  gyro  bias  com¬ 
pensation  updating  by  matching  compensated  gyro  rates  to  earth  rate  if  enabled 
by  the  control  panel  switches. 

Self-Test.  Task  24  (SIMINT)  is  a  self-test  initialization  module,  pro¬ 
viding  initial  values  for  position,  velocity,  and  other  kinematic  parameters 
for  the  100  Hz  self-test  driving  function  SIMULT,  SIMINT  is  iterated 
once  only  at  the  start  of  the  self-test  processing.  This  task  is  queued  by 
Task  34. 

Task  25  (SIMULT)  is  the  self-test  driver,  whose  purpose  is  to  com¬ 
pute  simulated  (100  Hz)  IMU  data  and  simulated  (1  Hz)  reference  data. 

Since  the  self-test  processing  takes  place  much  faster  than  real  time, 

SIMULT  is  iterated  at  a  rate  much  greater  than  100  Hz  (as  are  the  100-Hz 
navigation  and  alignment  tasks  also).  SIMULT  simulates  (unrealistic) 
high-dynamic  flight  conditions  so  that  the  navigation  and  alignment  modules 
are  extensively  exercised.  Since  only  a  checksum  test  is  performed,  the 
fact  that  these  conditions  are  unrealistic  is  of  no  importance.  This  task 
is  queued  by  Task  34. 

Task  32  (TESTDP)  is  queued  up  the  first  time  the  test  interrupt 
button  on  the  control  panel  is  pushed  after  a  reset.  It  determines  that  the 
memory,  arithmetic,  and  control  boards  are  present  in  the  DP. 

Task  33  (EIUTES)  is  queued  up  the  second  time  the  test  interrupt 
button  on  the  control  panel  is  pushed  after  a  reset.  It  tests  the  BIU's  to 
insure  that  they  respond  to  command  words. 

Task  34  is  queued  up  the  third  time  the  test  interrupt  button  on  the 
control  panel  is  pushed  after  a  reset.  It  tests  the  DP  ha  rdware  and  software 
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by  executing  the  navigation  and  alignment  tasks  for  a  simulated  60  seconds 
using  known  inputs.  Then  it  computes  a  checksum  over  part  of  operand 
memory  and  compares  it  to  a  precomputed  checksum.  This  task  queues  up 
Tasks  11,  14,  15,  16,  17,  18,  22,  23,  24,  and  25. 

SYSTEM  TESTS 

This  subsection  reports  the  results  of  tests  which  were  performed  on 
various  combinations  of  hardware  and  software  elements  of  the  DPI  system. 
These  tests  range  from  detailed  testing  of  individual  software  functions  in  a 
laboratory  environment  through  complete  system  testing  in  a  flight  environ¬ 
ment. 

Expected  Navigation  Performance 

The  required  level  of  navigation  performance  was  not  specified  for 
the  DPI  system.  However,  a  design  goal  of  1600  feet  (la)  in  each  axis  at  the 
end  of  a  10-minute  free  navigation  period  following  system  alignment  was 
used  in  the  development  of  system  software.  The  principal  error  sources 
to  be  considered  are  IMU  parameter  deviations  from  nominal  values,  tilt 
misalignment,  and  software  computation  error  (algorithm  truncation,  round 
off,  limited  precision,  etc.  ).  In  lieu  of  a  detailed  error  allocation  to  the 
elements  of  the  system  software,  the  design  philosophy  was  to  make  the  com¬ 
putation  error  contributions  to  total  navigation  error  small.  The  measured 
computation  errors  are  presented  in  the  following  section. 

For  several  reasons,  the  performance  of  the  transfer  alignment  soft¬ 
ware  could  not  be  quantitatively  predicted.  First,  the  superficial  structure 
of  the  filter  (number  of  states,  measurement  model,  etc.  )  was  derived, 
developed,  and  verified  by  covariance  analysis,  a  main-frame  computer  pro¬ 
gram  which  measures  the  performance  of  the  filter  relative  to  a  more 
elaborate  truth  model.  No  truth  model  of  manageable  size,  however,  can 
be  complete,  and  so  the  performance  measure  is  probably  optimistic  to  some 
slight  but  indeterminate  degree. 

Worse  yet,  the  fixed-point  implementation  in  DP  assembly  language 
forced  some  unforeseen  structural  deformations  in  the  filter,  the  impact  of 
which  could  not  be  assessed— by  covariance  analysis,  or  otherwise— in  the 
short  time  scale  allowed  for  software  development.  ,  The  process  noise,  for 
example,  which  optimized  the  covariance  analysis  filter  model  could  not  be 
faithfully  reproduced  in  the  fixed-point  version;  this  is  discussed  in  some 
detail  in  the  DPI  alignment  software  documentation.  The  filter  iteration 
rate  used  in  the  covariance  analysis  was  6  Hz;  in  the  finished  software,  how¬ 
ever,  a  more  promising  rate  of  1  Hz  was  adopted.  Moreover,  the  gyro  bias 
estimation  feature  was  added  as  an  afterthought  and  though  it  assumed  a  very 
reasonable  and  convincing  form  in  the  finished  software,  no  verification  of 
its  performance  (or  the  theory  of  operation,  for  that  matter)  existed  before¬ 
hand,  either  in  the  literature  or  in  the  form  of  a  simulation. 

Using  the  covariance  analysis  as  a  guide,  and  some  rough  calcula¬ 
tions  of  filter  sensitivity  to  gyro  bias,  a  set  of  residual  estimation  errors 
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wore  promulgated  which,  if  actually  approached  l^y  the  DPI  alignment  soft¬ 
ware,  would  constitute  success,  These  are: 


Tilt  misalignments  1  arc-minute 

Az;imuth  misalignment  3  arc-minutes 

Gyro  bias  0.2  degree/hour 

Since  the  uncompensated  gyro  biases  expected  in  the  Hamilton-Standard 
3030  IMU  are  fully  an  order  of  magnitude  greater  than  the  last  figure 
(2  degrees/hour  as  opposed  to  0.2  degree/hour),  the  untested  gyro  bias 
estimation  module  appeared  to  be  a  good  gamble. 

System  navigation  performance  is  shown  as  a  function  of  tilt  mis¬ 
alignment  and  gyro  bias  in  Figure  55.  The  effect  of  the  azimuth  misalign¬ 
ment  error  is  dependent  on  the  azimuth  maneuvers  during  free  navigation. 

If  the  average  azimuth  maneuver  during  free  navigation  were  Ig  then  the 
navigation  error  due  to  this  source  would  be  equivalent  to  that  shown  for  tilt 
misalignment.  In  the  absence  of  an  azimuth  maneuver,  azimuth  misalign¬ 
ment  error  only  produces  a  second  order  effect  on  navigation  error  through 
its  coupling  of  earth  rate  into  the  attitude  parameters. 

Laboratory  Tests 

A  series  of  laboratory  tests  were  performed  both  at  Hughes  and  at 
CIGTF,  The  emphasis  in  the' laboratory  tests  at  Hughes  was  on  the  verifi¬ 
cation  of  the  software  modules  and  the  integration  of  the  software  with  the 
Hughes-developed  hardware  and  the  Hamilton  Standard  IMU.  The  CIRIS 
interface  with  this  equipment  was  simulated  during  this  phase  of  testing. 

Tests  involving  the  IMU  at  Hughes  were  primarily  static  although  limited 
dynamic  conditions  were  used  in  some  tests. 

The  laboratory  tests  at  CIGTF  were  concerned  with  integration  of  the 
HP2100  computer  (CIRIS  simulation)  with  the  other  system  elements,  and 
system  level  tests  with  the  IMU  both  in  a  static  environment  and  using  coning 
motion.  Subsequent  paragraphs  provide  the  detailed  results  of  the  labora¬ 
tory  tests. 

Software  Module  Tests.  The  executive  software  modules  were  extensively 
tested  prior  to  their  integration  with  the  other  system  software.  Executive 
software  testing  during  this  phase  involved  the  use  of  test  drivers  which 
simulated  the  system  software  modules  interfacing  with  the  executive. 

These  test  drivers  exercised  both  the  executive  software  and  the  system  hard¬ 
ware  elements  in  a  high  stress  environment.  The  test  environment  was  much 
more  stringent  than  the  actual  system  operating  environment  and,  thus, 
ensured  adequate  capability  to  accomplish  the  system  testing. 

The  following  navigation  and  alignment  software  module  tests  also 
involved  the  use  of  test  drivers  to  simulate  the  operations  of  the  other  sys¬ 
tem  software  and  hardware  elements.  These  tests,  therefore,  did  not  use 
the  weapon  bus,  interface  hardware,  or  the  executive  software. 


Quaternion  Update /Direction  Cosine  Matrix  (Portion  of  Task  9).  The  attitude 
determination  portion  of  the  navigation  software  was  driven  using  simulated 
coning  motion  as  well  as  high  constant  angular  rates  about  one  axis.  The 
constant  rate  input  about  one  axis  produced  no  error  and  merely  checked 
scaling  and  gross  code  errors.  Coning  motion  exercised  the  quaternion 
algorithm  so  that  a  good  accuracy  assessment  could  be  made.  Test  results 
showed  that  the  adaptive  (dynamic  scaling)  algorithm  is  very  accurate.  Fig¬ 
ure  56  shows  the  /  axis  error  in  the  direction  cosine  matrix  versus  time 
during  coning  motion, 

a)  =  A  sin  (iJt) 


u)  =  A  cos  (u)t) 

y 

(J  =0 

7. 

with  A  =  0.4575695  rad/sec,  =  20.  0951483  rad/sec.  This  corresponds  to 
a  coning  half  angle  of  1.  3  degrees  at  a  coning  frequency  of  3.2  Hz.  Drift 
rate  for  this  test  case  was  0,  17  degrees/hour.  A  36-bit  floating  point  machine 
showed  a  0.  07  degree /hour  drift  using  a  direction  cosine  algorithm  with  the 
same  forcing  function.  Less  violent  motions  than  the  above  will  have  con¬ 
siderably  less  computation  induced  drift  than  0.  17  degree/hour. 
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Figure  56.  Coning  Motion  Z  Axis,  - - -  ,  Error  Relative  to 

Analytic  Solution 
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'  Velocity  and  Position,  Gravity  and  Coriolis  Corrections,  Navigation  Frame 

*  Rotations  (Portions  of  Tasks  9  and  ll)«  These  lilocks  of  code  were  checked 

‘t  against  analytic  results.  The  differential  equations  solv'cd  for  checkout  were 

i  contrived  (that  is,  simplified)  in  the  case  of  the  Gravity  and  Coriolis  Correc¬ 

tions  and  the  Navigation  Frame  Rotations.  Upper  liounds  on  the  calculation 
}  biases  include  0.01  degree/hour  in  the  Navigation  Frame  Rotations,  1,  5  x 

j  10"'^  ft/sec^  in  Coriolis  Corrections,  while  calculation  scale  factor  errors 

'  cause  0.  008  percent  error  in  latitude  movement  r.nd  ~0.  005  percent  error 

in  longitude  movement.  Small  statistical  variations  occur  in  the  latitude 
and  longitude  calculations  with  a  simplified  analysis  showing  an  error  with 
a  standard  deviation  of  26.6  feet  in  5  minutes.  Some  of  the  calculation  error 
sources  could  be  fixed  but  were  not  fixed  since  IMU  randomness  easily 
swamps  all  of  them. 

!  As  an  example  of  the  checkout  analysis  performed,  the  following  test 

I  of  the  coriolis  and  latitude /longitude  code  was  made.  With  the  body  acceler¬ 

ations  and  vertical  velocity  forced  equal  to  zero,  the  navigation  equations 
j  simplify  to 


=  V^(L  +  2U)  sinX 
v^  =  -  +  2f2)  sinX 


I  • 


X  = 


'N 

Tl 


•  w 

T.  “  cos  X 

where 

=  north  velocity 
=  west  Velocity 
X  =  latitude 


=  longitude 

Pt  =  R  (1  -  e,  2  -  3  sin^X) 
Li  e 

^  \  =  Rg  ( ^  ®  sin^  X) 


Rg  is  earth's  equatorial  radius  (20925695  feet)  and  e,  earth's  eccentricity 
(1/298.  3).  The  differential  equations  for  Vjsj  and  V\\r  are  still  too  compli¬ 
cated  for  solving.  By  NOP'ing  certain  lines  in  the  G&C  code,  V\\f  is  forced 
to  zero  and  the  equations  become 


-V 


V 


Vw(- 


w 


N  W'  P^cosA 


+  2S7)  sin  \ 


v„  =  o 


Letting  ,\  and  L  be  initially  zero  and  then  noting  that  \  will  not  change  appreci¬ 
ably  over  a  few  minutes, 


~^W 

.yo)  ^  “^W*p^(0)  ^  P^{  o') 


Letting 


+  2f2)  ^ 


W'Px(O) 


Pl(o) 


the  differential  equation  satisfied  by  becomes 


V  +  u)  V  =  0 
N  '^N  ^ 


The  solution  to  this  equation  is 


o 


S 

and  then 


''n  =V‘  =  “> 

o 


Vj^(t  =  0)  =  0  since  \  =  0  at  t  =  0 


\  = 


cos  wt 


Pl 


sin  wt 

o _ 

wPl 


L  = 


-V^l 


P)^(cos\) 


average 


With  the  initial  conditions  Vw  =-2048  ft/sec,  Vn  =  2048  ft/sec,  L  -  \  = 

0  degrees  (large  velocities  were  desired  to  see  the  small  coriolis  effects), 
measured  and  analytic  results  are  shown  in  Table  5.  The  velocity  error  is 
very  small  and  is  easily  accounted  for  by  the  worst  case  1.  5  x  lO"’  ft/sec^ 
icnov/n  error  (1.5  x  10”"  x  300  =  0.  045  ft/sec).  However,  the  small  Vjj  error 
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and  no  V-^  error  does  not  account  for  the  error  in  latitude  and  longitude.  A 
detailed  analysis  reveals  the  error  sources  to  be  calculation  limitations  in 
forming  PL“^  ^.nd  cos  (X)"^ .  At  X  =  0  degree, Pl“^  is  0.  008  percent 

too  small  and  P  x."  ^  co's  (X)"^  is  ~  0.  0045  percent  too  small.  The  error  in 
explains  the  latitude  error  but  the  error  in  P\"^  cos  is  smaller 
and  opposite  in  sign  to  the  measured  error.  A  detailed  examination  of  the 
code  with  the  specific  west  velocity  of  -2048  ft/ sec  revealed  a  rounding 
error  peculiar  to  the  longitude  channel  of  -0.0142  percent.  A  code  state¬ 
ment  was  subsequently  added, but  no  further  verification  was  warranted. 

TABLE  5.  EXPERIMENTAL  VERSUS  ANALYTIC  RESULTS 
AFTER  5  MINUTES  (299.  9  SECONDS) 


VARIABLE 

MEASURED 

ANALYTIC 

ANALYTIC  -  MEASURED 

NORMALIZED  ERROR  (%) 

''n 

2045.7803  FT/SEC 

2045.7888  FT/SEC 

0.0085  FT/SEC 

4.15  X  10 

X 

0.02953617  RAD. 

0.02953873  RAD. 

2.56  10®  RAD.  OR  53.5  FT 

0.0087% 

L 

0.02935975 

0.02935SS14 

4.24  X  10®  RAD.  88.6  FT 

0.0144% 

i 


Alignment  Filter  (Tasks  16,  17,  22).  An  abbreviated  driving  routine  was 
written  in  DPI  a  ssembly  language  for  the  specific  purpose  of  testing  the 
alignment  software  package  (1)  within  the  processor  itself  (i.e.,  an 
on-line  test),  and  (2)  in  the  absence  of  the  executive  and  navigation 
software  functions,  which  were  themselves  undergoing  stand-alone  tests. 
Initial  values  for  tilt  misalignments  (6isi>  about  the  North  and  West 

axes  were  postulated  in  the  driver,  and  navigation  errors  were  calculated 
by  the  deterministic  equations: 


North  velocity  error  = 
West  velocity  error  = 
Latitude  error  = 


Longitude  error  = 


-gt  sin{b^J^)  =  -gt  6^ 

+gt  sin(6N)  =  gt  6]^ 

1  2 

-  2  gt  sin(6^)/Re 

■  I 

1  2 

-  2  gt  sin(6j^)/Re  cos(X)  , 

■  7  cos(X) 
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where 


g  =  gravity  =  32.  2  ft/soc 

Re  =  Earth  equatorial  radius 
\  =  latitude  ; 

the  driver  then  chilled  the  alignment  modules  to  estimate  misalignments, 
reducing  the  initial  misalignments  by  the  estimated  values.  This  process 
was  iterated  many  times,  calculating  navigation  errors  from  the  residual 
misalignments  and  calling  the  alignment  filter. 

Assuming  initial  tilts  of  3  degrees  to  5  degrees,  it  was  found 
that  the  prefiltcr  leveling  routine  reduced  these  errors  to  several  arc- 
minutes,  and  fewer  than  20  iterations  of  the  Kalman  filter  further  reduced 
them  to  a  stable  limit  of  less  than  1  arc-second.  (Azimuth  misalignment 
estimates  were  consistently  nil,  which  was  the  correct  answer  for  these 
tests,)  Of  course,  these  impressive  results  were  not  indicative  of  the 
ultimate  performance  of  the  alignment  function,  when  operating  in  a  noisy 
environment  and  with  many  other  navig.ation  disturbances.  All  that  W'as 
convincingly  demonstrated  by  these  tests  was  that  there  was  no  gross 
logical  error  present  in  some  of  the  filter  modules,  and  that  the  package 
was  in  fact  endowed  with  a  capacity  for  misalignment  estimation.  The 
next  step  was  to  test  the  alignment  function  in  the  integrated  software 
package. 

Gyro  and  Accelerometer  Compensation  (Portion  of  Task  9).  The  compensa- 
tion  software  was  checked  by  static  testing  with  the  IMU,  The  test  set-up 
is  shown  in  Figure  57.  Special  test  software  was  used  to  drive  the  execu¬ 
tive  (for  data  formatting  and  bus  transfers)  and  to  accumulate  IMU  data. 

By  accumulating  raw  and  compensated  gyro  and  accelerometer  data  for  a 
fixed  time  interval  in  the  positions  X  axis  up  and  down,  Y  axis  up  and  down, 

Z  axis  up  and  down,  the  compensation  for  accelerometer  and  gyro  bias, 
gyro  input  and  spin  axis  unbalance,  and  accelerometer  scale  factor  could 
be  verified. 

A  typical  Z-axis-up  laboratory  data  sheet  is  shown  as  Figure  58. 

The  IMU  is  warmed  up  on  a  fairly  level  table  with  Z-axis-up  and  compen¬ 
sated  and  uncompensated  gyro  and  accelerometer  outputs  are  accumulated 
double  precision  for  100  seconds  and  then  recorded.  A  rotation  of  180  deg¬ 
rees  about  the  vertical  (Z  in  this  case)  axis  is  made,  and  the  100-second 
accumulation  is  repeated.  Averaging  of  the  0  degree  and  180  degrees  azi¬ 
muth  data  removes  the  Earth  rotation  rate  azimuth  uncertainty  as  well  as 
table  tilt  uncertainties.  With  the  Hamilton  S^^andard  sensor  axes  defined  as 
in  Figure  69  and  Z^^  pointing  up,  the  accelerometer  and  gyro  averages 
measure  the  following  forces  and  rates  over  a  100-secohd  period: 

=  X  accelerometer  bias  +  g  (tilt  about  Y  axis  of  IMU  body  | 

with  respect  to  table) 

i 

Ay  =  Y  accelerometer  bias  +  g  (tilt  about  X  axis  of  IMU  body  * 

with  respect  to  table)  I 


g  +  Z  accelerometer  bias 
X  gyro  bias 
Y  gyro  bias 


=  Z  gyro  bias  -g.  (Z  gyro  Spin  Axis  Unbalance)  +  Vertical 
component  of  Earth  Rate 

Performing  the  accumulations  in  all  the  various  positions  and  then 
averaging  and  rescaling,  a  table, such  as  that  shown  as  Table  6  here,  can 
be  generated. In  Table  6  raw  and  compensated  gyro  azimuth  averaged 
accumulations  are  listed  in  degrees/hour.  In  the  third  numerical  column, 
Lhe  measured  raw  data  is  differenced  from  the  appropriate  Hamilton 
Standard  compensation,  e.g.,  the  first  row  entry  is  X  gyro  raw  data 
(-27.  85  degrees/hour)  -  HS  calibrated  X  gyro  bias,  the  second  is  Y  gyro 
raw  data  (37.69  degrees/hour)  -  HS  calibrated  Y  gyro  bias  and  the  third  is 
Z  gyro  raw  data  (13.  18  degrees/hour)  -  HS  calibrated  Z  bias  +  g  (HS 
calibrated  spin  axis  unbalance).  That  the  compensated  data  closely  agrees 
with  the  Raw-HS  column  means  that  this  part  of  the  compensation  code  is 
correct  and  the  HS  calibration  constants  have  been  correctly  converted. 
The  Gyro  Error  column  gives  the  system  error.  With  the  correctly 
calibrated  compensation,  the  IMU  axes  should  measure  0  degree/hour  or 
else  8.  16  degrees/hour,  the  vertical  component  of  Earth  rste. 
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Figure  57.  Compensation  Software  Test  Setup 


Although  the  data  used  in  this  table  was  taken  at  Holloman,  numerous 
tests  identical  to  this  were  made  at  Hughes.  These  tests  were  required 
every  time  a  new  HS  calibration  was  made  in  order  to  check  out  the  new 
software  constants.  In  addition,  many  tests  were  made  just  to  monitor 
IMU  performance  and  make  sure  the  HS  calibration  was  reasonable. 


Accelerometer  b'as  and  scale  factor  (gravity  constant  is  known)  can 
also  be  verified  with  these  tests.  The  gyro  scale  factor  can  be  verified  by 
making  an  accurate  180  degrees  rotation  during  a  100-second  accumulation 
period.  The  compensation  not  checkable  by  the  fairly  crude  Hughes  test 
setup  included  gyro  and  accelerometer  sensor  to  body  axis  misalignments 
as  well  as  the  pseudo  coning  constant.  In  these  cases,  it  had  to  be  suffi¬ 
cient  to  visually  check  the  code  against  the  desired  equations  a  number  of 
times . 
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Figure  68.  DGWT  Laboratory  Tests 


TABLE  6.  GYRO  COMPENSATION  ANALYSIS 


MEASUREMENT 

POSITION 

QUANTITY 

MEASURED 

RAW  DATA 
VALUE  (°/hr) 

COMP.  DATA 
VALUE  (®/hr) 

RAW  -  H.  S. 

(SHOULD  EQUAL  COMP.) 

GYRO 
ERROR  ®/hr 

X 

Bx 

-27.85 

-1.24 

-1.29 

-1.24 

zT 
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By 
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NOMENCLATURE:  B  -  BIAS  ("/hr),  SA  -  SPIN  AXIS  UNBALANCE  (“/hr/g) 

lA  -  INPUT  AXIS  UNBALANCE  ("/hr/g),  ER  -  EARTH  RATE 


System  Integration  Teats  (Hughes).  This  portion  of  the  laboratory  tests  at 
Hughes  involved  the  integration  of  all  system  software  functions  —  executive, 
system  management,  navigation,  alignment,  instrumentation,  and  self  test — 
with  the  system  hardware  elements.  Since  the  HF2100  computer  of  the 
CIRIS  was  not  available,  its  functions  were  simulated  either  by  hardware  or 
software  depending  on  the  type  of  test  being  performed. 

In  integrating  the  executive,  navigation, and  alignment  software  func¬ 
tions,  there  ensued  a  brief  period  of  struggle  with  incorrect  calling  sequences, 
improper  relative  priorities,  and,  in  general,  the  inevitable  mismatches 
which  result  when  programs  written  by  more  than  one  person  are  rnerged. 

The  resolution  of  these  problems  was  straightforward,  and  once  the  integrated 
software  appeared  to  be  functioning  in  some  fashion,  a  new  period  of  testing 
began,  with  the  object  being  to  determine  whether  the  software  was  function¬ 
ing  properly,  and  if  so,  how  well.  This  period  was  considerably  protracted, 
in  part  because  the  processor  itself  had  some  residual  hidden  faults  and 
developed  more  along  the  way  and  also,  in  parti  because  of  a  lack  of  instru¬ 
mentation  for  measuring  performance  quantitatively. 
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The  integration  involved  two  fundamentally  different  types  of  experi¬ 
ment.  One  required  the  development  of  an  assembly- language  (  on-line  ) 
simulation  program,  which  was  to  reside  within  the  processor  and  generate 
simulated  IMU  outputs  and  simulated  reference  data.  Initial  values  for  mis¬ 
alignment  and  gyro  bias  were  selectable,  and  the  program  could  simulate  a 
static  test  (equivalent  to  sitting  still  on  the  Earth's  surface),  level  flight,  or 
flight  test  complete  with  three  3-minute  S-turn  maneuvers.  The  other 
experiment  —  true  static  alignment  —  required  using  the  actual  outputs  of  the 
IMU,  with  constant  reference  data  being  transmitted  to  DPI  from  a  test  box 
(HF2I00  simulation). 

Static  alignment  tests  of  the  second  type  were  sporadically  performed 
throughout  the  integration  period;  the  results  of  these  tests  were  ambiguous 
for  a  considerable  period.  The  alignment  filter  uses  three  periods  of  5 
minutes  each  to  remove  initial  tilt  misalignments  (first  period)  and  to  com¬ 
pensate  for  estimated  gyro  bias  (next  two  periods).  At  the  end  of  each  gyro 
bias  estimation  period,  the  alignment  filter  control  feedback  corrects  the 
gyro  bias  parameters  in  the  navigation  compensation  software.  The  expected 
result  of  executing  the  control  feedback  is  a  monotonic  decrease  in  residual 
gyro  bias.  Initial  static  alignment  tests  showed  an  apparent  discrepancy  in 
the  control  feedback  gyro  bias  gain  between  the  X  and  Y  gyros.  The  results 
of  the  second  bias  estimates  were  always  less  than  the  magnitude  of  the  first 
estimates,  indicating  convergence  of  the  estimator.  This  type  of  behavior 
was  apparent  in  all  static  alignment  tests  and  detailed  examination  of  the 
software  involved  did  not  result  in  any  changes. 

At  this  point,  it  was  decided  to  perform  tests  using  the  simulation 
software  routine  which  simulates  a  perfect  IMU  (except  for  preset  mis¬ 
alignment  and  bias  errors)  and  the  reference  system.  As  a  first  step,  the 
simulation  set-up  was  for  zero  velocity  to  duplicate  the  static  alignment 
with  the  IMU.  The  static  alignment  tests  using  the  simulation  showed  proper 
operation  of  both  the  navigation  and  alignment  filter  and  the  residual  bias  was 
reduced  to  1 ,  5  percent  of  the  initial  value.  Correct  results  were  also  obtained 
with  the  simulation  operating  at  a  constant  velocity  of  600  fps.  However, 
these  results  were  obtained  only  after  disabling  the  position  matching  in  the 
alignment  filter  (only  velocity  matching  was  used).  The  symtomatic  behavior 
of  the  alignment  filter  with  both  position  and  velocity  matching  was  the  gener¬ 
ation  of  a  large  azimuth  misalignment  estimate,  which  should  not  occur  in 
this  type  of  testing  since  no  lateral  acceleration  was  being  applied.  The  cause 
of  this  problem  was  found  to  be  a  persistent  position  error  rate  when  the 
corresponding  velocity  error  was  essentially  zero.  A  position  error  rate 
with  no  velocity  error  can  be  due  to{l)  inadequate  accuracy  in  the  scale 
factor  which  converts  a  distance  increment  to  a  Lat/Long  increment  and/or 
^)  truncation  error  in  determining  the  distance  increment.  Attempts  to 
null  the  position  error  rate  by  changing  the  scale  factor  in  the  simulation 
program  were  not  successful.  The  most  probable  cause  was  lack  of  precision 
in  determining  the  position  increment  in  the  simulation  since  this  routine  is 
performed  at  100  Hz.  Subsequent  testing  of  the  alignment  filter  proceeded 
uaing  only  velocity  matching  in  order  to  minimize  the  number  of  potential 
error  sources. 
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As  previously  mentioned,  static  alignment  tests  do  not  allow  verifica¬ 
tion  of  the  azimuth  misalignment  estimate  since  the  only  driving  function  in 
these  tests  is  the  inaccurate  compensation  of  sidereal  rate  due  to  coordinate 
system  rotation.  A  lateral  maneuver  is  required  to  obtain  proper  performance 
of  the  azimuth  channel.  The  simulation  software  allows  a  maneuver  to  be 
simulated.  With  the  maneuver,  a  number  of  problems  arose,  all  involving 
matching  the  simulation  results  with  the  corresponding  navigation  outputs 
under  error-free  conditions.  One  source  of  these  problems  was  found  to  be 
a  defect  in  the  navigation  quaternion  update  algorithm  under  large  dynamic 
conditions,  which  was  corrected. 

Since  static  alignment  is  proper  using  the  simulation  program,  inves¬ 
tigation  of  the  IMU  static  alignment  problem  was  initiated  by  attempting  to 
determine  what  is  different  between  the  simulated  IMU  and  the  actual  IMU 
environment.  One  possibility  involved  the  noisy  nature  of  the  IMU  outputs 
rather  than  the  well-behaved  deterministic  simulation.  A  second  difference 
is  that  the  simulation  tests  bypass  the  navigation  IMU  compensation  software. 
These  possibilities  were  investigated  by  first  adding  a  noise  sequence  to 
the  simulation  output  and  then  testing  the  compensation  software  with  a 
noise  sequence.  Proper  performance  was  found  in  both  cases.  Next,  the 
possibility  that  the  gyro  biases  were  not  constant  with  time  were  investigated. 

All  IMU  gyro  bias  measurements  were  made  after  an  adequate 
stabilization  period.  Initial  tests  showed  variations  of  l°/hr  peak-to-peak 
using  a  series  of  100-second  averaging  intervals  spaced  at  approximately 
5-minute  intervals.  Neither  the  navigator  nor  the  alignment  software  were 
operating  during  these  tests.  The  next  series  of  tests  used  a  series  of  con¬ 
secutive  5-minute  averaging  periods  within  a  30-minute  period.  Both  the 
navigator  and  alignment  filter  were  operating  during  these  tests,  but  free 
navigation  was  not  performed.  By  running  the  alignment  software  and 
additional  test  software,  the  performance  of  the  alignment  filter  in  estimating 
gyro  bias  and  the  response  of  the  compensation  software  to  the  bias  estimates 
were  independently  verified.  The  longer  averaging  period  reduced  the  peak- 
to-peak  bias  variation  to  0.  3  -  0.4O/hr.  In  general,  the  results  of  these 
tests  indicated  that  the  alignment  filter  estimate  of  gyro  bias  becomes  more 
accurate  when  the  actual  gyro  bias  is  stable  with  time.  In  fact,  the  alignment 
filter  estimate  error  was  greater  than  the  peak-to-peak  variation  in  actual 
bias,  indicating  a  probable  dependence  of  filter  performance  on  the  higher 
frequency  components  of  the  gyro  bias.  This  dependence  could  not  be  veri¬ 
fied  in  our  tests  due  to  inadequate  instrumentation  facilities. 

To  aid  in  diagnosing  the  effect  of  bias  variations  on  alignment  filter 
performance,  the  instrumentation  software  for  CIGTF  testing  was  modified 
to  allow  post-testing  analysis.  Rather  than  only  instrumenting  the  last  IMU 
samples  prior  to  the  instrumentation  request,  all  samples  of  both  raw  and 
compensated  IMU  data  are  accumulated  during  the  period  between  instrumen¬ 
tation  requests  and  the  results  will  be  output.  This  data  may  then  be  analyzed 
to  determine  variations  in  IMU  performance  over  varying  time  intervals  and 
the  response  of  the  alignment  filter  to  these  variations.  It  should  be  noted 
that  the  accumulation  period  is  matched  (approximately)  to  the  iteration 
period  of  the  alignment  filter. 
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During  the  course  of  subsequent  testing,  a  number  of  software  and 
hardware  faults,  as  well  as  procedural  errors,  were  discovered  and  cor¬ 
rected:  these  are  enumerated  below.  Which  of  these  were  present  and 
detracting  from  earlier  performance  is  not  precisely  known. 

(1)  Extraneous  clock  interrupts  were  found  to  be  occurring,  due  to  a 
noisy  inverter  in  the  clock  divide  chain.  Some  of  the  software 
tasks  were  therefore  being  queued  up  too  often  and  at  odd  times. 

(2)  A  tri-state  multiplex  chip  in  the  IMU  interface  circuitry  was 
found  to  be  bad;  although  it  was  discovered  in  a  stable  failure 
mode,  it  may  be  that  intermittent  failure  was  occurring  earlier. 

(3)  During  simulated  alignment  maneuvers  the  filter  convariance 
matrix  sometimes  becomes  increasingly  nonsymmetric  and  the 
misalignment  estimates  diverged  catastrophically.  This  type 
of  nonsymmetry  injection  was  not  foreseen,  and  was  immune  to 
the  symmetry-protection  features  of  the  software.  A  brute- 
force  symmetrization  routine  was  added  to  prevent  any  recurrence. 

(4)  A  source  of  inaccuracy  in  the  gyro-bias  estimation  was  also  found 
and  purged  with  a  resulting  small  improvement  in  performance. 

The  original  design  accumulated  misalignment  estimates  at  a  high 
(8x)  scaling  for  use  in  bias  estimation.  However,  the  incremental 
estimates  Nvere  shifted  down  —  as  a  fail-safe  hedge  against  over¬ 
flow  problems  —  before  being  used  to  correct  the  navigation 
attitude  quaternion,  with  a  consequent  precision  loss  affecting 

the  accumulated  estimate.  After  ascertaining  that  overflow  was 
not  occurring,  the  shift  was  permanently  removed. 

(5)  In  order  to  imitate  the  temporal  spacing  of  the  TIME  SYNC  and 
DATA  TRANSFER  COMPLETE  interrupts  from  the  HP2100,  the 
DPI  test  box  used  INTERRUPT  0  (a  null  task)  transmissions  as 
spacers.  The  unexpected  result  of  each  such  transmission  was 
that,  when  execution  of  an  interrupted  task  was  resumed,  further 
interrupts  were  masked  off  by  the  system  management  until  execu¬ 
tion  was  completed.  A  number  of  other  timing  schemes  were  later 
used  which  did  not  have  this  defect. 

(6)  It  was  not  recognized  at  first  that  the  HP2100  data  transfer  inter¬ 
rupt  spacing  was  inappropriate  for  the  simulation  tests.  This  is 
because  the  simulation  software  updates  the  reference  data  at  a 
100-Hz  rate,  requiring  that  the  reference  and  navigation  states 
be  sampled  with  no  more  than  100-msec  intervening  delay.  Some 
improvement  in  performance  was  evident  after  this  was  ensured. 

At  the  end  of  this  integration  period,  static  alignment  with  the  IMU 
appeared  to  be  satisfactory;  that  is,  tilt  misalignment  and  horizontal  (X-  and 
Y-  axis)  gyro  bias  estimates  were  reproducible,  and  successive  bias  estimates 
appeared  to  converge  rapidly.  Without  some  independent  means  of  determining 
misalignments  or  gyro  biases,  the  static  alignment  accuracy  could  not  be 


quantitatively  measured.  When  simulating  the  conditions  of  static  alignment, 
it  was  found  that  residual  tilt  misalignments  are  typically  less  than  one  arc- 
minute  and  residual  gyro  biases  less  than  0.  l°/hr.  When  flight  conditions 
with  alignment  maneuvers  are  simulated,  the  typical  performance  may  be 
summarized: 

0.  6  arc -minute  tilt  misalignment 

5  arc -minutes  azimuth  misalignment 

0.  3°/hr  bias,  Y-  and  Z-axis  gyros 

0.  9°/hr  bias,  X-axis  gyro. 

The  azimuth  alignment  and  X-axis  bias  compensation  accuracies  indi¬ 
cated  are  considerably  worse  than  expected;  however,  it  is  quite  likely  that 
this  inaccuracy  was,  in  large  measure,  an  artifact  of  precision  losses  in  the 
simulation  software.  The  large  residual  X-axis  (roll  axis)  bias, in  particular, 
appeared  to  be  due  to  the  rather  large  roll  rates  encountered  in  simulated 
alignment  maneuvers,  which  tended  to  aggravate  the  simulation  precision 
loss  problem.  Since  the  system  software  was  performing  substantially  as 
expected  and  a  major  design  effort  would  be  required  to  improve  the  simula¬ 
tion  software  precision,  the  system  was  shipped  to  CIGTF  for  further  inte¬ 
gration  tests. 

System  Integration  Tests  (CIGTF).  The  initial  integration  period  after  system 
delivery  to  CIGTF  was  involved  with  installation  of  the  equipment  in  the  racks 
and  interfacing  with  the  HP2100  computer.  All  interface  problems  concerning 
the  HP2100  computer  involved  hardware  incompatibilities  or  HP2100  software. 
Two  problems  were  discovered  and  corrected  in  the  DPI  instrumentation 
software  during  this  period  (one  parameter  omission,  one  data  formatting). 

In  the  laboratory  tests  which  followed,  the  HP2100  computer  was  pro¬ 
grammed  to  output  reference  data  (CIRIS  simulation).  The  altimeter  data  was 
also  simulated.  System  navigation  tests  were  performed  with  the  IMU  in 
both  a  static  environment  and  a  rotational  environment. 

These  tests  normally  start  with  the  IMU  physically  aligned  with  X  axis 
North,  Y  axis  West, and  Z  axis  up.  The  alignment  Kalman  filter  is  run  for 
fine  alignment  and  residual  tilts  and  gyro  drifts  after  the  alignment  period 
are  determined  by  monitoring  North  and  West  velocity.  Various  movements 
of  the  IMU  box  after  the  alignment  is  finished  (free  navigation)  included  180° 
yaw  turns,  15“  roll  and  pitch  turns  (the  table  limits  these  to  15°),  and 
Scorsby  tests.  These  laboratory  tests  are  easy  to  monitor  and  error  sources 
are  therefore  easily  isolated.  It  will  be  apparent  in  the  test  discussion  to 
follow  that  the  IMU  error  sources  swamp  all  other  possible  sources  of  error. 

The  earliest  laboratory  test  runs  were  made  in  late  September  and 
results  are  shown  here  as  Table  7.  Unless  specifically  stated  otherwise, 
all  tests  were  made  with  X  axis  North,  Y  axis  West,  and  pitch,  roll,  yaw 
reference  angles  of  0,0,0.  Also,  the  gyro  bias  is  adjusted  prior  to  align¬ 
ment  so  that  the  compensated  gyro  outputs  correctly  match  expected  Earth 
rate.  Since  no  lateral  maneuvers  can  be  made  in  the  laboratory,  no  informa¬ 
tion  about  the  vertical  axis  gyro  drift  is  available  to  the  alignment  filter. 
Taking  out  Z-axis  turn-on  to  turn-on  drift  is  essential  for  analyzing  per¬ 
formance  results. 
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For  the  tests  in  Table  7  the  standard  deviation  of  accumulated  gyro 
pulses  (164  seconds  summation  period)  is  shown  as  well  as  the  mean  difference 
between  the  gyro  output  during  and  after  alignment.  In  the  static  tests,  the 
mean  difference  should  appear  directly  in  the  free  navigation  drift.  Test 
number  10  shows  a  large  difference  in  mean  drift  of  0.  677°/hr  in  the  Y  gyro. 
The  result  is  that  a  drift  of  0.  56°/hr  shows  up  on  free  navigation  along  the 
West  axis  and  North  position  error  is  large.  The  performance  results  in 
Table  7  are  reasonable  considering  the  raw  gyro  variations,  and  distance 
errors  here  should  be  typical  of  the  minimum  possible. 

In  October  1976,  tests  were  made  involving  a  180°  yaw  turn  after 
free  navigation  and  30  to  60  minutes  of  tilt  appeared.  The  problem  was  iso¬ 
lated  to  a  bad  X  accelerometer  as  well  as  an  incorrect  program  statement. 
Sending  the  IMU  back  to  Connecticut,  Hamilton  Standard  replaced  the  X 
accelerometer  and  recalibrated  the  IMU. 

Table  8  lists  performance  data  on  the  tests  of  26  through  28  October 
1976.  Using  velocity  error  versus  time  to  fit  tilts  and  gyro  drifts,  the  dis¬ 
tance  error  after  10  minutes  of  flight  was  computed  and  is  shown  in  the  right- 
hand  columns.  Typical  velocity  profiles  for  some  of  the  tabulated  tests  are 
shown  in  Figures  60  and  61. 

The  static  tests  of  26  through  28  October  1976  are  good  and  compare 
with  the  September  1976  tests.  Scorsby  tests  show  larger  distance  errors, 
but  the  frequency  of  rotation  was  0.  2  Hz  and  0.  3  Hz  as  opposed  to  0.  1  Hz. 
Judging  from  the  quality  of  the  IMU,  it  is  likely  that  the  poorer  performance  at 
higher  coning  frequencies  is  due  to  the  IMU  and  not  the  software.  Coning 
motion  tests  show  reasonably  siinilar  performance  to  other  tests  not  involving 
continuous  motion. 

An  analysis  of  the  180°  yaw  turn  experiments  will  illustrate  how  useful 
the  controlled  laboratory  is  in  determining  the  origin  of  error  sources.  The 
large  drift  of  -1  to  -1,  6o/hr  will  be  traced  to  an  X  gyro  anomoly.  The  larger 
tilts  for  the  180°  yaw  tests  over  the  static  tests  are  reasonably  attributed  to 
gyro  and  accelerometer  misalignment  errors. 

A  simple  analysis  shows  that  gyro  and  accelerometer  misalignments 
as  well  as  accelerometer  "bias  errors  result  in  tilt  errors  appearing  after  a 
180°  turn  is  made  in  free  navigation.  Quantitatively,  twice  the  accelerometer 
misalignment/bias  error  and  3,  1416  times  the  gyro  misalignment  error  will 
appear  following  at  180°  turn.  Table  9  shows  the  misalignment  matrices 
provided  by  Hamilton  Standard  for  use  in  software  compensation.  Variations 
or  inaccuracies  of  0.  5  minute  in  the  third  column  entries  of  TAB  and  TGB 
would  account  for  most  of  the  increased  tilt  in  the  180°  yaw  tests.  Compensa¬ 
tion  tests  (accumulation  of  raw  data  with  Z  up  X  North  and  South,  Z  down  X 
North  and  South,  Y  up  ... )  show  that  accelerometer  bias  should  account  for 
0.  1  to  0.  2  minute  of  tilt.  On  top  of  these  error  sources  is  IMU  randomness. 

A  few  arc-minutes  of  residual  tilt  is  therefore  not  unreasonable. 

The  North  drift  in  the  180°  yaw  tests  particularly  documents  the  IMU 
anomolies  with  which  this  navigation  system  has  to  content.  The  following 

analysis  shows  that  the  residual  North  drift  following  a  180°  yaw  turn  should 
be  small  or  at  least  smaller  than  West  drift.  Remember  that  a  180°  yaw 


TrST  DESCRIPTION 

ALL  TESTS  PERFORMED  WITH 

TEST 

IMU  X-AXIS  POINTING  NORTH, 

TEST 

NO. 

IS  minute  ALIGNMENT 

i  DATE 

1  1 

RESIDUAL 

TILTS 


RESIDUAL 

DRIFT 


TABLE  7.  STATIC  TEST  SUMMARY  OF  28-30  SEPTEMBER  1976 


RESIDUAL 

TILTS 

RESIDUAL 

DRIFT 

NORTH  NAV 
ERROR 
DISTANCE 
(ft) 

WEST  NAV 
ERROR 
DISTANCE 
(ft) 

TIME  OF 
POSITION 
ERROR 
(min) 

RAW  GYRO  SI.  DEV. 
DURING  ALIGN/NAV. 
164  Mc  SUM  PERIOD 

RAWGYRO  DIFFERENCE 

IN  MEAN  VALUE  IN 
ALIGN/NAV  MODE* 

WITH 

IRTH, 

■ 

TEST 

DATE 

Sn 

(min) 

sw 

(iriin) 

“•n 

(°/llr) 

‘’w 

(°/hr) 

X 

»°/hr) 

Y 

(°/hr) 

(°/hr) 

X 

(°/hr) 

(°/bt) 

(°%r) 

09/28 

0.26 

-a43 

aoi4 

-a047 

2066 

543 

11 

0.073 

a066 

0.059 

0.08 

-0.049 

-a068 

09/29 

2.33 

0.99 

a4o° 

0.02° 

2407 

1506 

11.8 

0.223 

ai37 

0.180 

-0.01 1 

0.273 

-0.0125 

09/30 

VERY 

SMALL 

-0.89 

VERY 

SMALL 

-0.109 

4294 

-282 

15 

0.226 

a6oi 

0.029 

0.188 

-0.062 

-0.025 

09/29 

1.35 

0.43 

-a  128 

0.383 

-2830 

-3614 

21 

0.064 

aio4 

0.029 

-0.082 

0.161 

-0.024 

ATCH 

09/29 

a36 

1.34 

a087 

-0.120 

-1483 

-1471 

12 

a064 

0.104 

0.029 

a  082 

0.161 

-0.024 

09/28 

-2.38 

-0.34 

aio8 

-a84 

- 

- 

0.047 

0.076 

0.035 

0.069 

0.022 

0.047 

09/28 

1.99 

VERY 

SMALL 

a096 

VERY 

SMALL 

-230 

1925 

8 

0.036 

0.071 

0.043 

-0.044 

-0.073 

-a069 

09/30 

-461 

-4289 

16.3 

0.069 

a077 

0.0815 

- 

- 

- 

09/30 

-2877 

-3209 

12 

0.177 

a  922 

0.728 

■ 

- 

- 

- 

09/29 

VERY 

SMALL 

-a  174 

VERY 

SMALL 

a67 

-7262 

-260 

13.6 

0.136 

a  426 

0.152 

0.082 

0.677 

_ 1 

-0.14 

DRIFT  SHOULD  APPEAR  AS  AND  Y  AS 
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TILTS 

DRIFT 

nif;TANrp  frrdr 

TEST 

NO. 

TEST 

DATE 

TEST  DESCRIPTION 

S|^  (min) 

(rtiin) 

(°/hr) 

(°/hr) 

NORTH  (ft) 

WEST  (ft) 

1 

STATIC,  S  mlnut*  ALIGNMENT 

10/26 

VERY 

SMALL 

-a632 

VERY 

SMALL 

-0.07 

941 

-364 

2 

180°  YAW,  5  minute  ALIGN 

2  minute  FREE  NAV.  6  mln. 
AFTER  TURN 

10/26 

-3,62 

2.41 

-1,27 

a42 

-1575 

-2614 

3 

18°  PITCH  DOWN,  5  minute 
ALIGN.  2-1/2  FREE  NAV. 

7-1/2  mlnutei  PITCH 

10/26 

1.29 

— 

0.405 

— 

-1021 

2614 

4 

18°  ROLL  UP,  18  minute 

ALIGN.  2  mln.  FREE  NAV. 

7  minutes  ROLL, 

10/26 

Z26 

-0.68 

-Z29 

1.35 

-1719 

-1535 

6 

180°  YAW  16  minute  ALIGN 

6  mln.  FREE  NAV. 
fr1/2  mln.  ROTATE 

10/27 

-1.75 

-1.61 

— 

-2632 

-2109 

6 

180°  YAW,  16  minute  ALIGN 

1  mln.  FREE  NAV.  6-1/2  min. 
ROTATE 

10/27 

-Z8B 

-3.78 

-1.03 

-a22 

-2646 

-4559 

7 

180°  YAW,  18  minute  ALIGN 

1  mln.  FREE  NAV. 

6-1/4  mln.  ROTATE 

10/27 

-a7B 

-Z66 

-a  84 

-a8i3 

3224 

-  1141 

8 

STATIC,  8  minute  ALIGNMENT 

10/28 

-a523 

-ai7B 

-ai39 

-a222 

-1188 

1903 

9 

180°  YAW,  8  mi(iute  ALIGN 

YAW  TURN  RIGHT  AFTER 

FREE  NAV. 

10/28 

-a477 

0.308 

-0.962 

-a363 

796 

-3663 

10 

STATIC,  6  minute  ALIGN 
+8°  ERROR  IN  YAW  EULER 
ANGLE 

10/28 

-a475 

-a2i 

-a  286 

0.336 

-695 

-1264 

11 

180°  YAW,  8  minute  ALIGN 
-1^6°  ERROR  IN  YAW  EULER 
ANGLE 

10/28 

-1.18 

a886 

-1.11 

3.00 

-8027 

-3623 

12 

SCORSBY,  3°  HALF  ANGLE 
a2  Hz,  8  mla  ALIGN 

1/2  min.  FREE  NAV. 

7-3/4  mln.  SCORSBY 

10/28 

a26 

-a34B 

0.774 

1.03 

-1965 

2274 

13 

SCORSBY,  3°  HALF  ANGLE 
as  Hz,  3  minutes  AFTER 

ABOVE  TEST 

10/28 

a28 

-a349 

1.00 

3.00 

-6362 

5964 

u- 


r 


TABLF  8.  STATIC  TEST  SUMMARY  OF  26-28  OCTOBER  1976 


DRIFT 

TIME 

CALCULATED  DISTANCE 
ERROR  USING  GYRO 

TILT  ERROR  IN 

TOTAL  CALCULATED 

°/hr) 

(°/hr) 

NORTH  (ft) 

WEST  (ft) 

(minutei) 

NORTH  (ft) 

WEST  (ft) 

NORTH  (ft) 

WEST  (ft) 

NORTH  (ft) 

WEST  (ft) 

TEST  TYPE 

^LL 

-0.07 

941 

-364 

8 

392 

- 

1063 

- 

1455 

- 

STATIC 

27 

0.42 

-1575 

-2614 

6 

-2355 

-7120 

-4054 

-6089 

-6409 

-13209 

180°  YAW 
TURN 

405 

- 

-1021 

2614 

7-1/2 

- 

2270 

- 

2170 

- 

4440 

16°  PITCH 

29 

1.36 

-1719 

-1535 

7 

-7568 

-12838 

1144 

3785 

-6424 

-9053 

16°  ROLL 

1' 

- 

-2632 

-2109 

6-1/4 

- 

-9026 

-2944 

- 

-11970 

180°  YAW 

13 

-0.22 

-2646 

-4569 

6-1/2 

1233 

-5774 

-6358 

-4844 

-6126 

-10618 

180°  YAW 

4 

-a813 

3224 

-1141 

6-1/4 

4558 

-3027 

4306 

-1262 

8864 

-4289 

180°  YAW 

39 

-a222 

-1188 

1903 

10-1/2 

-1246 

779 

294 

880 

-961 

1659 

STATIC 

62 

-a363 

796 

-3663 

9 

2036 

-5392 

-518 

-802 

1617 

-6194 

180°  YAW 

16 

0.336 

-695 

-1264 

8 

-1M4 

-1603 

353 

-799 

1531 

-2402 

STATIC 

6°  YAW 
ERROR 

1 

3.00  ‘ 

-8027 

-3623 

7-3/4 

-16818 

-6223 

1490 

-1934 

-18308 

-8157 

180°  YAW 

6°  YAW 

U 

1.03 

-1965 

2274 

7-3/4 

-5774 

4339 

587 

420 

-5187 

4759 

CONING 

3°  HALF 
ANGLE  AT 

0.2  Hz- 

1 

3.00 

-6362 

6954 

3  min. 
AFTER 
ABOVE 
TEST 

-16918 

5606 

587 

420 

-16231 

5186 

CONING 

3°  HALF 
ANGLE  AT 

0.3  Hz 
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turn  keeps  the  same  gravity  field  as  was  present  during  alignment  (hence, 
there  are  no  spin  axis  or  input  axis  unbalance  effects)  and  that  gyro  and 
accelerometer  misalignments  and  accelerometer  bias  errors  result  in 
residual  tilts. 

The  only  remaining  explanation  for  the  large  residual  drift  following 
180°  yaw  turns  might  be  an  incorrect  gyro  bias  Earth-rate-match  due  to  an 
incorrect  azimuth  heading.  Assume  we  are  not  correctly  aligned  to  North 
by  an  azimuth  misalignment  of  -6.  Gyro  biases  are  adjusted  so  that 

=  n  cos  Uy  =0,  =  n  sin  X.. 


Referring  to  Figure  62,  the  actual  matching  should  be 


w  =  u  cos  \  cos  6  w  =  sink 


w  =  cos  X  sin  6 

y 


u 

UJ 


HL 


> 

u 

3 

Ui 


> 


vttocjXi 


OATiyl 


tLOClTV 


itOATtVf 


RELATIVE  TIME,  SECONDS 


Figure  60.  Typical  Velocity  Profiles,  Runs  1  through  3 
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Figure  6Z.  Miaalignment  Aaaumption 
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Figure  6l.  Typical  Velocity  Profiles,  Runs  5  and  6 


RUN  #6.  OCT  28 
6CORSBY  TEST  3 
ANGLE  AT  0.2  Ht 


CALIBRATION  ANALYSIS 

VARIABLE 

CONSTANT  OF  6/22 

CONSTANT  OF  10/22 

10/22-6/22 

ACCELEROMETER  X 

0.036927  ft/tac/pulia 

0.038561  ft/«ec/pulta 

SCALE  FACTOR 

1  •  10~®  ft/tac/pulta 

Y 

0,038767  ft/Mc/pulta 

0,038788  ft/tac/pulta 

Z 

0,037637  ft/tac/pulta 

0l037636  ft/tac/pulta 

—  1  •  10“®  ft/tac/puhe 

ACCELEROMETER  X 

-0.03176  ft/iac* 

0.01967  ft/ tec® 

BIAS 

Y 

-a02211  ft/«ac* 

-a02eiB2  ft/tec® 

-0.00407  ft/tac® 

Z 

0.04705  ft/tac* 

a0438S  ft/tec® 

-0.0032  ft/tac® 

GYRO  SCALE  X 

Ok 0624 166  mln/puha 

0.0624232  mln/pulta 

6k6  •  10“®  mln/pulte 

FACTOR 

Y 

0.0606418  mln/pulH 

a0606351  mln/pulta 

6.7"  10~®  mln/pulte 

Z 

0.056670  mln/pulte 

0.0566762  min/pulta 

6.2  •  10“®  mln/pulta 

GYRO  BIAS  X 

-27.81  “/hr 

-2ak66“/hr 

1.25“/hr 

Y 

33.66“/hr 

37.48“/hr 

3.82“/hr 

Z 

1.77“/hf 

2.06“/hr 

a29“/hr 

SPIN  AXIS  X 

-5.13“/hr/g 

-6.68“/hr/g 

-1.44°/hr/g 

UNBALANCE 

Y 

1.86°/hr/g 

a903“/hr/g 

a05°/hr/9 

Z 

-7.324“/hr/g 

a349“/hr/g 

7.67°/hr/g 

INPUT  AXIS  X 

-1.78“/hr/g 

-1.7l'’/hr/g 

a071°/hr/g 

UNBALANCE 

14.70°/hr/g 

Y 

16.76“/hr/g 

2.051°/hr/g 

Z 

6.314“/hr/g 

6.96“/hr/g 

a646“/hr/g 

t 


TABLE  9.  CALIBRATION  ANALYSIS  SUMMARY 


> 

10/22-6/22 

1  •  10~®  ft/«ec/pulfe 

—  1  •  10~®  ft/iac/pult# 

-0.00407 
-a0032  ft/sec^ 


CALIBRATION  ANALYSIS  lg/22 


1 

4.42  mrad 

0.948  mrad 

4.473  mrad 

1 

2.88  mrad 

—0.673  mrad 

aOIS  mrad 

1 

1 

15.196  min 

3.259  min 

15.377  min 

1 

9.90  min 

-1.970  min 

0.0516  min 

1 

CALIBRATION  ANALYSIS  6/22 


TAB 


1 

b.777  mrid 
—2.63  mr*d 


-0.0453  mrtd 
1 

0.48  mrid 


1.377  mrad 
2.257  mrad ' 
1 


1 

19.86  min 
—9.04  min 


-0.156  min  4.6  min 

1  7.76  min 

1.65  min  1 


&6  •  lO""®  min/pulte 
6.7  •  10~®  mln/pulia 
6.2  •  10~*  mln/pulia 

1.26°/hr 

3.82"/hr 

a29°/hr 


-1.44“/hr/o 

a.05°/hr/B 


1 

2.49  mrad 

0.2473  mrad 

1 

0.884  mrad 

2.342  mrad 

- 

-0.9925  mrad 

1 

0.644  mrad 

TGB  = 

0.36  mrad 

1 

0.221  mrad 

-0.1791  mrad 

-0.6625  mrad 

1 

2.507  mrad 

0.181  mrad 

1 

1 

8.56  min 

0.850  min 

1 

3.04  min 

8.05  min 

- 

-141  min 

1 

2.214  min 

> 

1.28  min 

1 

0.761  min 

—0.616  min 

-2.243  min 

1 

-8.62  min 

-0.621  min 

1 

7.67“/hr/g 

a071°/hr/9  1  fSin.  OF  ERROR  IN  THE  THIRD  COLUMN  OF  TGB  RESULTS  IN  A  TILE  OF  3.42  min  AFTER  A  180°  TURN. 

2.06l“/hr/g  1  min  OF  ERROR  IN  THIRD  COLUMN  OF  TAS  RESULTS  IN  A  TILE  OF  2  min.  AFTER  A  180°  TURN. 

a646°/hr/g 
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Erroneous  biases  of  S2cos  ( \)cos(6)-i7cos(\)  =  -f2cos(x)  and 
-S2cos(A)sin(6)-0  =  -P,cos(A)6  are  put  into  the  North  (X)  and  West  (Y)  gyros. 
Azimuth  misalignment  is  not  corrected  during  alignment  since  the  afcel- 

information  about  6.  Misalignment  exists  but  is 
statically  balanced  quite  well  as  test  number  10  shows.  Here  a  5-degree 
error  in  .aw  Euier  angle  induces  a  known  error  relative  to  the  other^static 
tests.  No  noticeable  degradation  from  other  static  tests  appears. 


follows 


Due  to  Earth  rate  matching,  the  static  balance  equations  read  as 


“  ‘^NAV  NORTH  “  f^cos{X.)cos(6)+b^  =  f2cos(X.) 


^ yj  ~  ^NAV  west  ~  “flcos(X.)sin(6)+b^  =  0 

With  a  180°  turn,  the  X  and  Y  compensated  gyro  outputs  measure 


W  =  -!flcos(X,)coa(6)+b 

*  X 


w 


y 


Dcos(\)sin(6)+b 


y 


Since  the 
frame  requires  w 


Z  (or  vertical)  gyro  measured  a  180° 
NAV  NORTH  ‘^NAV  WEST  ‘° 


turn, 


the  navigation 


‘*’’nAV  north  "  ■cos(\) 


"NAV  WEST 


or  else  a  residual  drift  will  arise. 

The  errors  are  then 

^N  "  ‘*^x’‘*'nAV  north  ~  ^"^'^°®^^)cos(6)+b^)-(-ncos(\)) 

=  2(f2co8(\)-S2cos(McoB(6)) 

2 

=  6  f2co8(X) 
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and 


“  “y'^^NAV  WEST  "  (^cos(X)sin(6)+by)-0 

=  2f2cos(X)sin(  6)  =  26f2cos(\) 


This  analysis  says  that  there  should  appear  a  West  gyro  drift  (North 
velocity  related)  but  no  North  drift.  A  5-degree  azimuth  misalignment  should 
reveal  a  West  drift  of  2.  20/hr  and  a  North  drift  of  0,  05°/hr  after  a  180°  turn. 
Test  number  11  bears  out  the  effect  of  azimuth  misalignment  on  West  drift. 
However,  all  of  the  180°  yaw  tests  show  an  unaccountable  North  drift  ranging 
from  -0.  54°/hr  to  -1.  6l°/hr. 

Two  raw  data  compensation  tests  revealed  that  the  problem  is  due  to 
the  X  gyro.  It  appears  that  the  X  gyro  bias  is  different  depending  on  whether 
the  axis  is  pointing  North  or  South.  The  compensation  test  results  were 

-1.77°/hr  additional  bias  South,  uncertainty  0.  68°/hr 

-2.0°/hr  additional  bias  South,  \mcertainty  l°/hr 

The  uncertainties  arise  from  table  levelness  and  are  upper  bounded  using 
alignment  test  results,  physically  estimating  table  levelness,  and  compen¬ 
sated  Z  gyro  North  and  South  accumulations.  A  tilt  of  3-1/2  degrees  about 
the  Y  axis  results  in  an  X  axis  gyro  North/ South  difference  of  2(8.  l6°/hr) 
sin  (3,  5°)  =  l°/hr.  In  one  of  the  above  compensation  tests,  the  Z  gyro  data 
indicated  a  maximum  of  3-1 /2-'degree  tilt.  These  tests  conclusively  point 
to  an  X  gyro  anomoly  which  is  unaccounted  for  in  the  compensation  equation 
formulations. 

Finally,  the  roll  .and  pitch  movements  of  15  degrees  are  again  reasona¬ 
bly  good.  Talsle  9  shows  that  spin  and  input  axis  unbalances  are  large  and 
since  the  sine  of  15  degrees  is  0.26,  uncertainties  in  these  quantities  can 
cause  large  residual  drifts.  The  compensation  test  results  .in  Table  10  even 
more  succinctly  show  how  the  navigation  performance  is  limited  by  the  IMU. 
Raw  and  compensated  gyro  outputs  are  accumulated  for  100  seconds  and  dis¬ 
played  in  units  of  degrees  per  hour  in  the  first  two  numerical  columns.  That 
the  Raw  data  minus  Hamilton  Standard  compensation  constants  is  very  close  to 
the  compensated  data  shows  that  the  compensation  software  is  correct.  Gyro 
errors  in  the  last  column  are  due  to  improper  HS  compensation  constants 
and/or  not  a  complete  enough  compensation  equation  formulation.  That  is, 
the  Y  gyro  behavior  for  Y  up  and  Y  down  implies  the  spin  axis  unbalance 
requires  a  gravity  squared  (g^)  compensation.  Hamilton  Standard  did  not 
provide  g2  compensation  coefficients,  probably  because  these  terms  vary 
wildly  from  turn-on  to  turn-on. 
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TABLE  10.  GYRO  COMPENSATION  ANALYSIS 


MEASUREMENT 

POSITION 

QUANTn  Y 
MEASURED 

RAW  DATA 
VALUE  (‘^/hr) 

COMP.  DATA 
VALUE  (“/hr) 

RAW  H.S. 

(SHOULD  EQUAL  COMP.) 

GYRO 
ERROR  °/hr 

X 

^x 

27.85 

1.24 

-1.29 

-1  24 

Y 

^Y 

37.69 

37.69 

.21 

.21 

Z 

82  SA4ER 

13.18 

13.18 

11.46 

3.31 

X 

®x 

27.47 

.875 

.91 

.875 

Y 

^Y 

37.35 

.12 

.13 

.13 

Z 

BAtSA  ER 

-9.98 

-12.39 

12.39 

-4.23 

X 

By 

25.11 

-.19 

.26 

.19 

Y+ 

Y 

By  SA+ER 

28.43 

.825 

.853 

7.335 

Z 

CD 

X 

> 

7.48 

-.536 

.54 

.536 

X 

B^.IA 

33.52 

-5.18 

5.25 

5.18 

Y4- 

Y 

By  I  SA  ER 

38.855 

8.515 

8.53 

-.355 

z 

B^  lA 

4.23 

.33 

.33 

-.33 

X 

1 

By  SA+ER 

17.81 

2.266 

2.17 

5.894 

xf 

Y 

By'  lA 

48  95 

5.285 

5.28 

5.285 

z 

«Z 

2.04 

0.25 

.02 

.025 

X 

B^ISA  ER 

40.30 

7.13 

7.16 

1.03 

x4^ 

Y 

B^-IA 

22.975 

2.26 

2.245 

2.26 

Z 

«Z 

.54 

1.53 

1.52 

1.53 

NOMENCLATURE:  B  -  BIAS  (°/hr),  SA  -  SPIN  AXIS  UNBALANCE  (°/hr/g) 

lA  -  INPUT  AXIS  UNBALANCE  (“/hr/g).  ER  EARTH  RATE 


In  conclusion,  the  laboratory  tests  give  some  idea  of  the  navigation 
performance  to  expect  in  the  van  or  aircraft.  The  IMU  limitations  are  clearly 
presented  and  will  have  to  be  considered  in  all  tests. 

Dynamic  Navigation  Tests 

Following  the  system  integration  tests,  the  DPI  system  was  installed 
in  a  van  for  dynamic  navigation  tests.  CIRIS  was  also  Installed  in  the  van  for 
these  tests.  Altimeter  data  was  simulated  (constant  altitude)  by  test  hardware. 

A  preliminary  analysis  of  various  navigation  tests  in  the  van  is  shown 
in  Table  11,  This  analysis  shows  that  the  navigation  performance  is  essen¬ 
tially  as  expected  based  on  laboratory  test  results.  Further  testing  of  the 
system  will  consist  of  aircraft  navigation  tests.  CIGTF  personnel  are  response 
ible  both  for  performing  all  dynamic  tests  and  for  the  detailed  analysis  of 
test  results.  Consequently, the  complete  analysis  of  system  performance  is 
not  contained  in  this  report. 


TABLE  11.  VAN  TEST  SUMMARY  OF  9  NOVEMBER  -  11  NOVEMBER 


TILTS 

DRIFT 

DISTANCE  ERROR 

TIME 

6|,^MINUTE 

6„,minute 

w 

t>^(“/HR) 

b^^(“/HR) 

NORTH  (FT) 

WEST (FT) 

(MINUTES) 

NO  EARTH  HATE 

match; 

STRAIGHT 

ROADS 

0.74 

-1.9 

0.277 

0.142 

1S50 

12'/. 

NO  ERM. 
SMOOTHLY 
CURVED  ROADS 

1.134 

0.33 

-0.113 

0.147 

_ • 

1628 

11 

NO  ERM. 

SHARP  90“ 

TURNS 

3.76 

-3.95 

0.636 

0,789 

1250 

2165 

6 

NO  ERM. 

SMOOTH  ROADS 
WITH  ACCELE¬ 
RATIONS  AND 
DECELERATIONS 

0.153 

0.663 

-0.277 

0.2S8 

1345 

492 

10 

SAME  AS  ABOVE 

-0.342 

-0.634 

0.322 

0.103 

-795 

99 

10 

NO  ERM.  SHARP 
TURNS,  ROCK¬ 
ING,  AND 
ACCELERATIONS 

0.355 

•3.37 

0.04 

0.107 

2964 

-219 

7 

CIRIS  HAD  A  LATITUDE  PROBLEM  ON  THIS  OaV. 
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Summary 

The  tests  made  with  the  DFl  system  ranged  from  detailed  testing  of 
individual  software  elements  in  a  laboratory  environment  to  complete  system 
testing  in  a  flight  environment. 

Laboratory  tests  were  performed  both  at  Hughes  and  at  CIGTF.  The 
Hughes  Aircraft  Company  laboratory  tests  were  directed  at  verification  of  the 
software  modules  and  integration  of  the  software  with  the  DF  hardware  and 
IMU.  The  CIGTF  laboratory  tests  were  aimed  at  integration  of  the  HP2100 
computer  (CIRIS  simulation)  with  other  system  elements  and  system  level 
tests  with  the  IMU  both  in  a  static  environment  using  coning  motion. 

In  the  software  module  tests  at  Hughes  Aircraft  Company,  the  execu¬ 
tive  software  was  verified  by  dynamic  testing  under  conditions  exceeding  the 
expected  requirements  for  CIGTF  operation.  The  results  achieved  in  the 
navigation  and  alignment  software  module  tests  are  summarized  below; 

(1)  The  navigation  software  performance  using  a  simulated  IMU 
(DF  software  test  driver)  matched  well  with  results  predicted 
by  analytic  simulation. 

(2)  The  alignment  software  quickly  converged  to  accurate  estimates 
of  misalignments  and  gyro  biases  which  were  input  from  a  soft¬ 
ware  test  driver  simulating  the  IMU  and  navigation  software. 

The  system  integration  tests  at  Hughes  Aircraft  Company  involved  the 
integration  of  all  the  system  software  functions  with  the  system  hardware 
elements.  At  the  end  of  the  integration,  static  alignment  with  the  IMU 
appeared  to  be  satisfactory:  tilt  misalignment  and  horizontal  gyro  bias  esti¬ 
mates  were  reproducible  and  successive  bias  estimates  appeared  to  converge 
rapidly, 

A  software  test  driver  capable  of  simulating  IMU  data  for  both  static 
alignment  and  alignment  maneuvers  was  used  for  system  level  verification 
of  the  DP  software.  For  simulated  static  alig '.ment  conditions,  it  was  found 
that  residual  tilt  misalignments  were  typically  less  than  one  arc-minute  and 
residual  gyro  biases  under  0,  l°/hr.  For  simulated  alignment  maneuvers, 
the  typical  performance  was  as  follows: 


Tilt  misalignment 
Azimuth  misalignment 
Bias,  Y  and  Z-axis  gyros 
Bias,  X-axis  gyro 


0.  6  arc -minute 


Expected  Error 
1  arc -minute 
3  arc -minutes 
0. 2°/hour 
0, 2°/hour 


5  arc -minutes 
0, 3°/hour 
0. 9°/hour 


The  azimuth  misalignment  and  X-axis  bias  were  found  to  be 
considerably  worse  than  expected,  as  indicated,  probably  due  to  precision 
losses  in  the  simulation  software. 

At  CIGTF,  system  navigation  laboratory  tests  were  performed  with 
the  IMU  in  both  a  static  environment  and  a  rotational  environment.  The 
following  is  a  summary  of  the  results  obtained. 

CIGTF  Laboratory  Tests 

(1)  Distance  error  performance  was  reasonable  for  the  expected 
IMU  error  sources.  The  tests  verified  the  DP  software. 

(2)  Residual  tilt  misalignment  and  gyro  biases  calculated  from 
velocity  error  histories  were  reasonable  for  the  raw  IMU 
gyro  variations. 

The  laboratory  test  indicated  the  expected  navigation  performance 
for  the  subsequent  dynamic  tests  in  the  van  and  aircraft. 

Following  these  tests,  the  DPI  system  was  installed  in  a  van  (with 
CIRIS)  for  dynamic  navigation  tests.  The  test  results  showed  that  the  nav¬ 
igation  performance  was,  in  general,  the  same  as  that  expected  based  on 
laboratory  test  results. 
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SECTION  IV 


HYBRID  SIMULATION 


The  CIGTF  operation  demonstrated  the  CORE  electronics  concept 
in  a  real  environment,  but  did  not  include  all  of  the  functions  which  the  CORE 
electronics  will  be  required  to  perform  in  a  tactical  system.  The  hybrid 
simulation  was  designed  to  include  all  of  the  CORE  functions  except  system 
test. 


The  concept  of  the  system  simulated  is  shown  in  Figure  63.  Basic¬ 
ally,  it  is  a  long-range  air-to- surface  weapon  which  uses  an  aided  inertial 
guidance  system  for  midcourse  guidance.  The  simulated  weapon  was  based 
on  the  GBU-15  system  with  appropriate  guidance  elements  added. 

The  simulation  was  performed  in  the  Hughes  Hybrid  Simulation 
facility  at  Canoga  Park,  California.  The  simulation  of  the  GBU-15  was 
originally  developed  for  the  PDAP  simulations  in  1975.  Some  modifications 
to  the  simulation  were  necessary  and  are  described  in  the  following  para¬ 
graphs.  The  entire  system  was  simulated  on  the  hybrid  computer  except 
for  the  digital  processor  in  the  CORE  electronics.  The  DP2  breadboard 
processor  was  used  to  emulate  the  CORE  digital  processor. 

SYSTEM  DESCRIPTION 

The  system  which  was  simulated  is  a  modular,  long  range,  air-to- 
surface  weapon.  It  has  a  midcourse  guidance  subsystem  which  can  fly  a 
pre-set  course  from  launch  point  to  the  target  area.  The  trajectory  is  not, 
in  general,  a  great  circle  route  or  a  straight  line.  Rather,  it  more  often 
will  be  a  segmented  path  to  allow  flying  over  intermediate  check  points  or 
to  allow  avoidance  of  some  point.  The  basic  guidance  is  strapdown  inertial 
which  is  implemented  with  an  inertial  measurement  unit  (IMU)  and  a  digital 
processor  to  perform  the  strapdown  inertial  calculations.  The  inertial 
guidance  system  is  not  accurate  enough,  by  itself,  to  achieve  the  required 
CEP  at  the  target  area;  therefore,  it  must  be  periodically  corrected  during 
the  flight.  The  correction  is  made  with  the  aid  of  a  position  sensor  such  as 
a  LORAN  receiver  or  a  GPS  receiver.  The  data  from  the  position  sensor  is 
smoothed  by  a  Kalman  filter  and  then  is  used  to  update  the  inertial  system's 
estimate  of  position. 

The  weapon  may  fly  all  the  way  to  the  target  via  the  inertial  guidance 
or  it  may  switch  to  a  terminal  guidance  system.  The  terminal  sensor  could 
be,  for  example,  a  readiometric  seeker  or  an  electro-optical  seeker.  In  the 
latter  case,  lockon  for  terminal  guidance  would  be  achieved  by  an  operator 
working  through  a  data  link. 

The  combination  of  the  digital  processor  and  the  IMU  is  thought  of  as 
the  core  electronics  for  the  weapon.  The  other  subsystems  (  airframe, 
warhead,  position  sensor,  terminal  sensor)  may  be  modularly  changed  to 
suit  the  operational  requirements,  but  the  core  electronics  remains  the 
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-  GBU-15  AERODYNAMICS 


LORAN 

RAC 

GPS 


Figure  63.  Weapon  to  be  Simulated 

same  in  all  configurations.  The  digital  processor  not  only  performs  the 
strapdown  inertial  calculations  but  also  does  the  autopilot  calculations  and 
the  system  integration  function. 

The  simulation  performed  was  a  semi-physical  simulation;  that  is,  a 
portion  of  the  system  was  simulated  by  a  hybrid  computer  and  the  remainder 
was  simulated  by  real  hardware.  In  this  case  the  real  hardware  was  the 
digital  processor  and  the  digital  weapon  bus. 

Airframe 

The  airframes  simulated  were  those  of  the  GBU-15.  The  GBU-15  is 
a  modular  weapon  with  two  major  aerodynamic  configurations:  a  weapon  with 
an  unfolding  planar  wing  and  a  cruciform  tail  which  is  referred  to  as  the 
planar-winged-v/eapon  (PWW)  and  a  weapon  with  a  set  of  cruciform  wings 
aligned  with  the  cruciform  tail  which  is  referred  to  as  the  cruciform-winged- 
weapon  (CWW).  The  control  surface  orientation  rer.idins  the  same  for  either 
aerodynamic  configuration.  Each  airframe  requires  its  own  autopilot.  The 
autopilot  configuration  is  selected  by  discrete  signals,  the  values  of  which 
are  determined  by  the  airframe  configuration  and  other  subsystems  which 
may  be  on  board. 

Core  Electronics 

The  core  electronics  consists  of  the  digital  processor,  the  weapon 
bus,  the  IMU.and  an  altimeter.  The  altimeter  is  required  to  keep  the  iner¬ 
tial  guidance  system  stable  in  the  vertical  channel.  Functionally,  the  core 
electronics  is  identical  with  the  corresponding  components  used  in  the 
CIGTF  operation  and  previously  described  in  Section  III. 
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In  the  simulation,  the  IMU  and  altimeter  functions  were  simulated. 
The  functions  of  the  digital  processor  and  the  weapon  bus  were  performed 
with  real  hardware:  the  DP2  system  which  is  described  in  the  following 
section. 

Position  Sensor 


The  function  of  the  position  sensor  is  shown  in  Figure  64.  As  shown 
in  the  figure,  the  basic  guidance  is  strapdown  inertial.  At  periodic  times, 
the  position  sensor  makes  an  accurate  determination  of  the  weapon  position 
and  the  position  data  are  used  to  update  the  inertial  estimate  of  position. 
Actually,  the  position  update  may  not  be  periodic  for  some  of  the  sensors. 
The  radiometric  area  correlation  (RAC)  sensor  makes  update  measurements 
at  preselected  check  points.  These  check  points, in  general,  will  not  be  on  a 
straight  line;  therefore,  the  guidance  law  may  have  to  compute  a  segmented 
trajectory  so  as  to  fly  over  the  check  points. 


As  indicated  in  the  figure,  several  possible  position  sensors  have 
been  suggested  for  use  in  an  advanced  weapon.  The  operation  of  any  of  them 
in  the  system  is  the  same  except  for  two  factors*. 

(1)  Some  of  the  sensors  require  a  shaped  trajectory  either  for 
passing  over  intermediate  check  points  or  for  terminal  guidance 
(if  they  are  used  for  terminal). 

(2)  Each  sensor  requires  a  different  transformation  applied  to  its 
output  data  before  it  can  be  used  to  update  the  inertial  system. 

Only  the  LORAN  sensor  was  used  in  the  simulation;  however,  the 
guidance  law  did  allow  segmented  trajectories  to  be  flown  as  would  be 
required  for  sensors  such  as  RAC  and  TERCOM, 

Terminal  Guidance 


The  terminal  guidance  subsystem  simulated  was  an  EO  seeker.  In 
real  operation  the  seeker  would  be  locked  on  to  the  target  at  initiation  of 
terminal  guidance  by  an  operator  working  through  a  data  link.  In  the  simu¬ 
lation,  the  operation  of  the  operator  and  data  link  was  not  simulated  in 
detail.  Rather,  the  function  was  simulated  by  pointing  the  simulated  seeker 
look  angle  at  the  target. 

SIMULATION  IMPLEMENTATION 

The  system  just  described  was  simulated  using  a  semi-physical  sim¬ 
ulation.  A  semi- physical  simulation  is  a  simulation  in  which  a  portion  of 
the  actual  physical  system  is  incorporated  into  the  simulation.  The  physical 
hardware  performs  its  expected  function  while  the  remainder  of  the  system 
functions  are  modeled  using  analogous  mathematical  functions  usually  on 
computers.  In  this  simulation  the  actual  physical  system  is  the  DP  and 
weapon  bus.  The  remainder  of  the  system  was  modeled  on  a  hybrid  com¬ 
puter  consisting  of  a  Sigma  8  digital  computer,  two  EAl  781  model  analog 
computers,  and  a  Beckman  2200  model  analog  computer. 


103 


Functional  Description 


The  major  functions  of  the  weapon  are  shown  in  Figure  65.  During 
the  launch  sequence,  initialization  information  is  received  across  an  inter¬ 
face  with  the  aircraft  stores  management  system.  The  system  management 
software  supervises  the  receipt  of  this  data,  placing  it  in  its  proper  operand 
memory  locations  and  placing  initialization  tasks  in  the  queue  as  the  proper 
data  is  received  from  the  aircraft  fire  control  system. 

At  detection  of  separation  of  the  weapon  from  the  aircraft,  the  sys¬ 
tem  management  software  starts  an  internal  clock  which  is  used  to  control 
periodic  tasks  and  time -dependent  selection  of  processing  alternatives.  The 
night  control  system  (autopilot)  provides  weapon  stabilization  and  steering 
based  upon  inputs  from  the  IMU  sensors  and  guidance  calculations.  The 
autopilot  sends  commands  to  the  flipper  actuators.  The  weapon  stabilization 
loop  is  closed  through  the  IMU  sensors  which  measure  the  vehicle  dynamic 
response  to  the  flipper  actuator  commands.  The  motion  of  the  flipper  on 
the  weapon  causes  the  aerodynamic  forces  to  change  which  induces  body 
motion  of  the  weapon.  The  changes  in  body  motion  are  detected  by  the  IMU 
sensors  which  send  the  information  to  the  autopilot  and  the  strapdown  iner¬ 
tial  navigation  calculations.  The  dynamic  motion  of  the  weapon  is  used  to 
determine  weapon  position,  velocity  and  attitude  data  in  both  the  strapdown 
inertial  navigation  processing  and  geometry  functions.  The  location  and 
velocity  of  the  weapon  calculated  by  the  strapdown  inertial  navigation  process¬ 
ing  are  used  by  the  guidance  law  to  generate  steering  signals  which  are  sent 
to  the  autopilot  for  yaw  plane  steering  in  the  midcourse  phase  of  weapon 
flight.  The  body  motion  changes  the  geometry  of  the  weapon  with  respect 
to  the  target  and  LORAN  stations,  and  the  geometry  calculation  of  weapon 
position  is  combined  with  the  LORAN  station  data  to  generate  LORAN 
receiver  outputs  during  midcourse.  The  LORAN  receiver  outputs  are  proc¬ 
essed  to  determine  weapon  position  data  which  are  used  to  correct  the  strap- 
down  inertial  navigator  via  an  alignment  (Kalman)  filter. 

The  geometry  calculations  of  weapon  position,  velocity,  and  attitude 
are  also  combined  with  target  position  data  to  generate  steering  signals  from 
the  £0  seeker  which  is  used  for  terminal  guidance.  Thus,  the  guidance 
(steering)  loop  is  closed  through  the  updating  of  the  geometry  function  which, 
in  turrv  ci^fects  the  guidance  sensor  outputs.  The  equipment  on  which  each  of 
the  system  functions  is  implemented  in  the  simulation  is  designated  in  each 
box  in  the  figure. 

Digital  Processor  Hardware 

The  basic  digital  processing  system  consists  of  a  digital  processor 
(DP)  and  a  serial,  multiplexed  digital  bus  which  is  called  the  Weapon  Bus. 

The  DP  can  communicate  with  other  subsystems  via  the  weapon  bus.  The 
interface  with  the  weapon  bus  is  by  means  of  a  bus  interface  unit  (BIU),  which 
formats  data  for  transmission  over  the  bus. 

In  the  simulation,  the  DP2  system  was  required  to  interface  with 
a  digital  and  an  analog  computer.  Since  neither  of  these  computers  has  an 
J»v«^rface  compatible  with  the  Weapon  Bus,  it  was  necessary  to  fabricate 
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Figure  64.  Inertial  Navigation  Update  Guidance  System 


CODE:  rT~l  DIGITAL  COMPUTER 
m  ANALOG  COMPUTER 
r~ri  OP  SYSTEM  HARDWARE 


Figure  65.  DP  Hybrid  Simulation 


two  additional  interface  units.  The  first  of  these,  called  the  Signal  Conver¬ 
sion  Interface  Unit,  provides  an  interface  with  the  analog  computer.  It 
provides  an  analog-to  -digital  and  digital-to-analog  conversion  function  as 
well  as  a  BIU- compatible  interface.  The  second  unit,  called  the  Sigma  8 
Interface  Unit,  provides  an  interface  with  the  digital  computer. 

A  block  diagram  of  the  DP2  system, as  it  was  used  in  the  Hybrid 
Simulation  Laboratory,  is  shown  in  Figure  66.  A  control  panel,  not  shown 
in  the  diagram,  allows  the  operator  to  monitor  and  control  the  system. 


SIGMA  8 
DIGITAL 
COMPUTER 


C^GITAL^ 


DIGITAL  ) 

EAI  793 
INTERFACE 

<C  ANALOG  &  LOGIC  | 

PARALLEL 

V 

V 

ASTRODATA 

INTERFACE 

BECKMAN 

2200 

EAI 

781 

#2 

CT^ALO^ 

EAI 

781 

#1 

Figure  66.  Block  Diagram  of  Hardware  Interfaces 
Used  in  Simulation 
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The  DP2  system  differs  from  the  DPI  (described  in  Section  III)  in 
two  ways.  First,  the  DP2  processor  has  an  extended  instruction  set. 
Second,  in  the  DP2  system,  the  Master  Bus  Control  Circuits  are  contained 
in  the  DP  cabinet.  In  the  DPI  system,  these  control  circuits  were  con¬ 
tained  in  one  of  the  BIU  boxes  which  was  called  the  Master  BIU.  This 
latter  change  simplifies  the  interface  between  the  DP  and  the  weapon  bus. 


A  detailed  description  of  the  DP2  system  is  given  in  the  report 
DGWT  0210-2,  Operating  Manual  and  System  Description  for  Digital  Proc¬ 
essor  Number  2.  The  instruction  set  for  the  processor  is  described  in 
DGWT  0170-2,  Programmer's  manual  for  PDAP,  DPI  and  DP2. 

Hybrid  Computer  Simulation 

A  hybrid  simulation  of  the  GBU-15  weapon  system  was  originally 
developed  for  validating  PDAP  performance  and  has  since  been  modified 
to  support  the  WCU  development  prograin  for  GBU-15.  A  functional  block 
diagram  of  the  baseline  GBU-15  simulation  is  shown  in  Figure  67.  Several 
modifications  were  required  to  the  baseline  configuration  to  incorporate  the 
additional  weapon  system  functions  for  the  DP2  simulation  effort.  The  new 
weapon  functions  were:  strapdown  inertial  navigation,  LORAN  data  process¬ 
ing  and  the  inertial  midcourse  guidance  law.  The  simulation  was  required 
to  not  only  furnish  the  appropriate  real  time  data  for  these  functions,  but 
also  initialization  data  via  a  simulated  avionics  interface  for  prelaunch 
weapon  preparation. 

The  only  interface  of  the  hybrid  computer  with  an  external  digital 
processor  was  via  analog  signal  lines  in  the  baseline  configuration.  How¬ 
ever,  a  digital  interface  was  desired  in  the  DP2  simulation  not  only  to  .sim¬ 
ulate  the  digital  avionics  interface  but  also  to  provide  adequate  resolution 
on  the  functional  interface  signals  (initialization  and  real  time).  Therefore, 
the  required  digital  interface  hardware  was  installed,  and  an  assembly 
language  program  was  written  to  allow  the  SIGMA  8  to  both  read  data  from 
and  write  data  to  the  digital  interface  unit. 

The  following  paragraphs  address  the  simulation  modifications  to 
incorporate  the  new  weapon  functions. 

Strapdown  Inertial  Navigation.  The  simulation  must  provide  angular  rate 
(or  incremental  angle)  and  acceleration  (or  incremental  velocity)  data  in 
the  three  missile  body  axes  to  DP2.  The  required  transfer  rate  (100  Hz) 
of  this  data  would  have  produced  loading  problems  in  the  SIGMA  8  if  the 
digital  interface  were  used  for  this  transfer.  Therefore,  the  simulated 
IMU  data  was  transferred  to  DP2  via  analog  signals.  Angular  rate  and 
acceleration  data  were  output  by  the  analog  computer  for  minimum  simu¬ 
lation  interface  complexity.  This  required  that  the  baseline  simulation 
be  modified  to  output  weapon  roll  rate  and  longitudinal  acceleration  signals 
in  addition  to  the  other  two  rate  and  acceleration  signals  already  existing. 

The  data  required  to  initialize  the  DP2  navigation  software  param¬ 
eters  were  output  by  the  SIGMA  8  via  the  digital  interface. 
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Figure  67.  Baseline  Simulation  Functional  Block  Diagram 


LQRAN  R('cri\cr  Function,  Tlu'  LORAN  rr(.i'i\ i' r  function  was  simulated 
by  a  FORTRAN  program  in  the  SIGMA  8  computi-r,  A  block  diagram  of  tht 
LORAN  simulation  is  shown  in  Figure  68.  This  program  determines  the 
master- slave  distance  diffcM-ences  corresponding  to  the  simulation  weapon 
}KJsition  for  each  of  the  two  sla\e  stations.  Distance  diffi-rence  data  was 
output  to  DP2  via  the  digital  interface  rather  than  the  more  customary  tirm 
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Figure  68,  Block  Diagram  of  Additiona  to  GBU-15  Simulation 
for  LORAN  Receiver  Type  Information 
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difference  data  output  of  a  LORAN  receiver.  However,  this  data  format 
difference  only  corresponds  to  a  scale  factor  discrepancy,  namely,  the  speed 
of  light.  The  scale  factor  was  compensated  in  LORAN  network  parameters 
sent  by  the  SIGMA  8  to  DP2  via  the  digital  interface  as  part  of  system 
initialization. 

Inertial  Midcourse  Guidance  Law.  The  simulation  modification  required  to 
support  the  DP2  midcourse  guidance  law  calculations  consists  of  outputting 
target  and  checkpoint  position  data  via  the  digital  interface  as  part  f)f  system 
initialization.  In  addition,  the  midcourse  guidance  Law  was  also  implemented 
by  a  FORTRAN  routine  on  the  SIGMA  8.  The  SIGMA  8  calculation  of  mid¬ 
course  steering  command  was  output  to  DP2  at  50  Hz  via  the  digital  interface. 
Selection  of  either  the  SIGMA  8  or  DP2  implementation  of  the  guidance  law 
was  made  by  modification  of  the  appropriate  DP2  memory  reference 
instruction. 

The  next  subsection  details  both  the  analog  and  digital  parameters 
which  are  transferred  between  the  hybrid  computer  and  DP2, 

Simulation  Interfaces 


A  block  diagram  of  the  hardware  interfaces  is  shown  in  Figure  69. 

The  signal  format  for  each  interface  is  shown  also.  There  are  four  types  of 
signals:  analog,  discrete  logic,  parallel  digital,  and  bit- sequential  digital. 
The  interface  between  the  DP2  equipment  and  the  SIGMA  8  is  parallel  digital. 

As  with  most  semi- physical  simulations,  special  purpose  interface 
hardware  is  required  to  create  a  compatible  interface  between  the  system 
hardware  and  the  modeling  hardware.  For  this  simulation  the  special  pieces 
of  hardware  were  the  digital  interface,  the  signal  conversion  unit,  and  the 
PDAP  buffer  amplifier.  The  digital  interface  contained  a  32-word  buffer 
storage  area  and  two  latches  for  storing  control  words  being  transferred 
in  either  direction.  The  signal  conversion  unit  converted  16  analog  signals 
to  digital  words  and  stored  them  in  latches.  At  the  end  of  the  A/D  conver¬ 
sion,  it  latched  the  status  of  16  discrete  logic  lines  into  another  digital  word. 
The  signal  conversion  unit  also  contained  three  D/A  converters.  The  signal 
conversion  unit  and  the  digital  interface  are  described  in  Report  No.  DGWT 
0210-2,  Operating  Manual  and  System  Description  for  Digital  Processor 
Number  2.  The  PDAP  buffer  amplifier  contained  19  operational  amplifiers 
to  buffer  between  the  A/D  and  D/A  converters  in  the  signal  conversion  unit 
and  the  analog  computer.  The  PDAP  buffer  amplifier  was  the  same  unit 
that  was  used  with  the  PDAP  simulation  effort.  The  signal  conversion  was 
basically  the  same  design  as  the  signal  conversion  unit  used  by  PDAP  but 
was  a  new  piece  of  hardware.  The  digital  interface  unit  was  a  new  design 
and  a  new  piece  of  hardware. 

Signal  Interfaces.  The  signal  interfaces  between  the  hybrid  computer  and 
the  DP2  system  are  shown  in  Figure  69.  The  three  signal  formats  are  dis¬ 
cussed  separately  below. 


DIGITAL  INTERFACE 


Analog  Signal  Interfaces .  Of  tlif  If)  available  analog  signals  from  the  analog 
computer,  only  13  were  required  for  the  DP2  simulation.  Of  these,  six  were 
used  exclusively  by  the  autopilot,  four  were  used  both  in  the  autopilot  an*"!  in 
the  inertial  navigation  calculations,  two  were  used  exclusively  for  inertial 
navigation,  and  one  was  used  both  in  the  inertial  navigation  and  the  guidance 
law  computations.  The  analog  interface  variables  are  listed  in  Table  12. 

Three  analog  signals  were  generated  by  the  autopilot  and  sent  to  the 
analog  computer  as  flipper  commands. 

Discrete  Logic  Signal  Interface.  Sixteen  discrete  logic  signal  lines  are  out¬ 
put  by  the  analog  computer  and  their  states  are  stored  as  a  16-bit  logic  word 
in  the  signal  conversion  unit.  Only  12  of  the  discrete  lines  must  be  energized 
by  the  analog  computer  to  accomplish  the  PDAP  functions.  The  locations  of 
the  active  signal  bits  in  the  DP2  logic  word,  DDVW,  and  their  function  in  the 
PDAP  are  shown  in  Table  13.  The  usage  of  these  bits  in  the  DP2  simulation 
effort  is  also  indicated  in  the  table.  This  logic  word  is  decoded  in  the  flight 
control  software  to  select  signal  sources  and  guidance  modes  for  weapon 
flight. 

Digital  Signal  Interface.  As  indicated  in  Figure  69,  the  digital  interface 
accommodated  four  functions. 

(1)  Initialization  data,  which  was  input  to  the  SIGMA  8  on  cards, 
was  sent  to  DP2. 

(2)  The  distance  differences  for  the  simulated  LORAN  receiver 
was  transmitted  to  the  DP2. 

(3)  The  navigation  results  from  the  DP2  were  sent  to  the  SIGMA  8 
for  conversion  to  analog  and  printing  on  a  strip  chart  recorder. 

(4)  •  The  optional  calculation  of  the  midcourse  guidance  law  (com¬ 

puted  in  the  SIGMA  8)  was  sent  to  the  DP2. 

The  digital  interface  signals  are  listed  in  Table  14. 
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TABLE  12.  INTERFACE  SIGNAl] 
AND  DIGITAL  PROCESSOR  i| 
(DIGITAL  GUIDED  WEAP 


HYBRID  COMPUTER 

ANALOG  INTERFACE  BOX 

SIGI 

A/D 

SIGNAL 

DESCRIPTION 

DIAGRAM 

SYMBOL 

DEFINITION  AND 
SIGNAL 

scale 

FACTOR 

PIN 

NO. 

AMPLIFIER 

TYPE 

GAIN 

(V/V) 

±10v 
=  RANGE 

RESULT) 

LSB 

PITCH  -  YAW 

FLIPPER  COMMAND 

®qc  “  ®rc 

+PITCH  “  NOSE  UP 

0.666v/o 

J4 

NON-INVERT 

1.0 

i15° 

0.0293° 

PITCH  +  YAW 

FLIPPER  COMMAND 

S  +  8 

qc  rc 

+  YAW=  NOSE  RIGHT 

0.666v/o 

J5 

NON-INVERT 

1.0 

±15° 

0.0293° 

ROLL  FLIPPER 
COMMAND 

Sp 

ROLL  CLOCKWISE 
(FROM  REAR) 

0.666V/O 

J6 

NON-INVERT 

1.0 

±15° 

0.0293° 

PITCH  ANGLE  OF 
SEEKER 

SEEKER  UP 

-a444v/o 

J7 

INVERT 

0.6 

±37.5 

0.0183° 

ANGLE  OF  ATTACK 

«M-  “c 

NOT  USED 

Iw/o 

J8 

NON-INVERT 

0.4 

ROLL  RATE  GYRO 

'■g 

ROLL  CLOCKWISE 

aSv/o/iac 

J9 

NON-INVERT 

0.2 

±  1 00°/.ec 

0.0488°/! 

LONGITUDINAL 

ACCELERATION 

■"x 

FORWARD 

6.66v/g 

J10 

INVERT 

0.2 

±7.5/g 

0.0037g 

PITCH  (VERTICAL 
ACCELEROMETER 

Nz 

UP 

-3.33v/g 

J11 

NON-INVERT 

0.4 

±7.5/g 

0.0037g 

YAW  ACCELERATION 

Ny 

RIGHT 

6.66v/g 

J12 

INVERT 

±7.5/g 

0.0037g 

PITCH  SEEKER 
DERIVED  RATE 

NOT  USED 

— 0.565v/o/mc 

J13 

INVERT 

YAWSEEKER 

DERIVED  RATE 

NOT  USED 

0.555v/o/mc 

J14 

NON-INVERT 

EO STEERING 

SIGNAL  (PITCH) 

Xp 

&33v/o/mc 

J16 

NON-INVERT 

0.1 

±12°/«»c 

0.0059°/) 

EO  STEERING 

SIGNAL  (YAW) 

— 8.33v/o/»»c 

J18 

INVERT 

0.1 

±12°/i«c 

0.0059°/s 

PITCH  ALTITUDE 

»G 

NOSE  UP 

-a277v/o 

J17 

INVERT 

±90.26° 

0.0441°/) 

YAW  ALTITUDE 

^G 

NOSE  RIGHT 

a277v/o 

JIB 

NON-INVERT 

±9a25° 

0.0441  °/s 

PITCH  RATE  GYRO 

''G 

NOSE  UP 

1,1  Iw/o/mc 

J19 

NON-INVERT 

±45°/«ec 

0.022°/se 

YAW  RATE  GYRO 

NOSE  RIGHT 
(FROM  REAR) 

—1.1  1v/o/mc 

J20 

NON-INVERT 

±46°/»»c 

0.022°/se 

ROLL  GYRO 

^G-  *c 

ROLL  CLOCKWISE 
(FROM  REAR) 

— 4.26v/o 

J21 

NON-INVERT 

+  117.5° 

a0574° 

ALTITUDE 

h 

ALTITUDE  ABOVE 
SPHERE  OF 

EARTH 

a002v/ft 

J22 

INVERT 

at 

50,000 

24.41  ft 

DISCRETE  LOGIC  LINl 

(TTie  reverse 


SE  RIGHT 


TABLE  12.  INTERFACE  SIGNALS  BETWEEN  THE  ANALOG  COMPUTER 
AND  DIGITAL  PROCESSOR  (DPI  DURING  HYBRID  SBiULATION 
(DIGITAL  GUIDED  WEAPONS  TECHNOLOGY  PROGRAM) 


X 

o 

o 

SIGNAL  CONVERSION  UNIT  (3CU) 
A/O  -  12  BITS  D/A  =  10  BITS 

DIGITAL 

PROCESSOR 

16-BIT 

DATA  WORD 

SCALE 

FACTOR 

MSB 

SCALE 

FACTOR 

PIN 

NO. 

AMPLIFIER 

TYPE 

GAIN 

(V/V) 

±10v 

RANGE 

BIU 

ADDRESS  (D) 

TYPE 

CONVERSION 

0.666v/o 

J4 

NON-INVERT 

1.0 

i15° 

0.0293° 

192 

D/A 

7.5° 

0t666v/o 

j:. 

NON-INVERT 

1.0 

±15° 

0.0293° 

193 

D/A 

7.5° 

0.666v/o 

J6 

NON-INVERT 

1.0 

±15° 

00293° 

194 

D/A 

7.5° 

-a444v/o 

J7 

INVERT 

0.6 

±37.5 

0.0183° 

64 

A/D 

18.75° 

Iw/o 

J8 

NON-INVERT 

0.4 

+  a 

65 

A/D 

aSv/o/sac 

J9 

NON-INVERT 

0.2 

±  1 00°/tac 

0.0488°/i«c 

^'■g 

66 

A/D 

50°/«ec 

&66V/S 

J10 

INVERT 

0.2 

±7.S/g 

O00370 

-N^ 

?7 

A/D 

3.75g 

-3.33v/g 

J11 

NON-INVERT 

0.4 

±7.5/g 

0.0037g 

-Nj, 

68 

A/D 

3.75g 

6.66v/g 

J12 

INVERT 

0.2 

±7.S/Q 

0.0037g 

-Ny 

69 

A/D 

3.75g 

-0.855v/o/t«c 

J13 

INVERT 

0.4 

70 

A/D 

a,55Sv/o/««c 

J14 

NON-INVERT 

a4 

71 

A/D 

&33v/o/t«c 

J1S 

NON-INVERT 

ai 

±12°/mc 

0.0059°/mc 

72 

A/D 

6°/i«c 

— 8.33v/o/mc 

J16 

INVERT 

0.1 

±12°/Me 

0.0059°/f«c 

73 

A/D 

6°/wc 

-a277v/o 

J17 

INVERT 

0.4 

±90.25° 

0.0441  °/«*c 

74 

A/D 

45.125° 

a277v/o 

J18 

NON-INVERT 

04 

±9026° 

0.0441  °/iec 

75 

A/D 

45.125° 

1.11v/o/*«c 

J19 

NON-INVERT 

±45°/««c 

0.022°/f«c 

76 

A/D 

22.5°/»«c 

-1.1 1v/o/wc 

J20 

NON-INVERT 

±4S°/»«c 

a022°/*»c 

-fG 

77 

A/O 

22.5°/mc 

-4.2BV/0 

J21 

NON-INVERT 

+  117.6° 

00574° 

”  ^G 

78 

A/D 

58.78° 

a002v/ft 

J22 

INVERT 

ai 

80,000 

24.41  ft 

-h 

79 

A/D 

25,000  ft 

DISCRETE 

LOGIC  LINES 

80 
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TABLE  1  3. 


DISCRETE  LOGIC  VARIABLES 


DLVW 

BtT 

rjAME 

— 

PDAP  FUNCTION 

DP2  SIMULA!  ION  USAGE 

SIC.N 

WEAPON  SEPARATION 

ENABLE  FLIGHT  CONTROL 

(NOT  USED  FUNCTION  BY 

SIGMA  8  INTERRUPT) 

14 

EOT  COMMAND 

COMMANDS  EO  TERMINAL  GUIDANCE 
(IF  0) 

SAME  AS  PDAP 

13 

LOBL 

SELECT  EO  TERMINAL  GUIDANCE 
THROUGHOUT  FLIGHT  (IF  0) 

NOT  USED  (SET  1) 

12 

TRANSITION  ENABLE 

ENABLE  TRANSITION  FROM  MID 
COURSE  TO  EO  TERMINAL  GUIDANCE 

SAME  AS  PDAP 

11 

CWM 

SELECT  CWW  FLIGHT  CONTROL 

SELECT  CWW  FLIGHT  CONTROL 

10 

PWM 

SELECT  PWW  FLIGHT  CONTROL 

NOT  USED  (ALWAYS  0) 

9 

EO  TAKEOVER 

ENABLE  EO/DL  MIDCOURSE 

GUIDANCE 

SET=  1  TO  ENABLE  INERTIAL 
MIDCOURSE  GUIDANCE 

8 

DMEI 

INDICATES  DME  MODULE  INSTALLED 

SELECT  RATE  GYRO  INPUTS 

FOR  STABILIZATIONS 

7 

EO  INHIBIT 

ENABLE  SWITCH  FROM  EO  TO  DME 
GUIDANCE 

NOT  USED  (SET  0) 

c 

5 

4 

DME  PITCHOVER 

ENABLE  DME  TERMINAL 

GUIDANCE 

NOT  USED  (SET  =  0) 

3 

2 

1 

EO/DL  STEER  MINUS 

DECREMENT  YAW  CMD  BY  1  degree 

NOT  USED 

0 

EO/DL  STEER  PLUS 

INCREMENT  YAW  CMD  BY  1  degree 

{ _ 

NOT  USED 

lABLE  14.  VARIABLES  PASSED  OVER  DIGITAL  INTERFACE 


DESCRIPTION  OF  VARIABLE 

FULL  SCALE 
VALUE 

INCOMING  VARIABLES  (SIGMA  8  -  DP2) 

SYMBOL 

FREQUENCY 

1. 

DISTANCE  FROM  GBU-15  TO  MASTER  LORAN  SEC¬ 
TION  MINUS  DISTANCE  FROM  GBU-15  TO  SLAVE  1 

2«1 

607,600  ft 

50  Hz 

2. 

DISTANCE  FROM  GBU-15  TO  MASTER  LORAN  STA¬ 
TION  MINUS  DISTANCE  FROM  GBU  15  TO  SLAVE  2 

2»2 

607,600  ft 

50  Hz 

3. 

MIOCOURSE  STEERING  SIGNAL 

Sh 

30  uniti 

50  Hz 

4. 

LAUNCH  VELOCITY  (NORTH) 

vn 

32,767  ft/tec 

I.C. 

5. 

LAUNCH  VELOCITY  (WEST) 

Vw 

32,767  ft/toc 

I.C. 

6. 

LAUNCH  VELOCITY  (UP) 

Vu 

32,767  ft/«ec 

I.C. 

7. 

LAUNCH  LATITUDE  {i  NORTH) 

^L 

V  ridicni 

I.C. 

8. 

LAUNCH  LONGITUDE  (+  CAST) 

Ll 

trridiani 

I.C. 

9. 

LAUNCH  ALTITUDE 

►’L 

50,000  ft 

I.C. 

10. 

LAUNCH  PITCH  ANGLE  (ORDER  p,  y,  r) 

Co 

rr  radiant 

I.C. 

11. 

LAUNCH  YAW  ANGLE 

Trradiant 

I.C. 

12. 

LAUNCH  ROLL  ANGLE 

TT  radiant 

I.C. 

13. 

TARGET  LATITUDE 

Xt 

Trradiant 

I.C. 

14. 

TARGET  LONGITUDE 

Lt 

77  radiant 

I.C. 

16. 

DESIRED  BEARING  ANGLE  TO  TARGET 

77  radiant 

I.C. 

16. 

CHECKPOINT  LATITUDE 

^CP(3) 

Trradiant 

I.C. 

17. 

CHECKPOINT  LONGITUDE 

‘-CP(3) 

Trradiant 

I.C. 

18. 

CHECKPOINT  ALTITUDE 

hCP(3) 

50,000  ft 

I.C. 

19. 

DESIRED  BEARING  ANGLE  TO  CHECKPOINT 

‘^DCP(3) 

Trradiant 

I.C. 

20. 

CHECKPOINT  LATITUDE 

^CP(2) 

Trradiant 

I.C. 

21. 

CHECKPOINT  LONGITUDE 

‘-CP(2) 

Trradiant 

I.C. 

22. 

CHECKPOINT  ALTITUDE 

*’CP(2) 

50,000  ft 

I.C. 

23. 

DESIRED  BEARING  ANGLE  TO  CHECKPOINT 

‘^DCP(2) 

Trradiant 

I.C. 

24. 

CHECKPOINT  LATITUDE 

^CP(I) 

77  radiant 

I.C. 

26. 

CHECKPOINT  LONGITUDE 

•-CP(I) 

rr  radiant 

I.C. 

26. 

CHECKPOINT  ALTITUDE 

*’CP(1) 

50,000  ft 

I.C. 

27. 

DESIRED  BEARING  ANGLE  TO  CHECKPOINT 

“^DCPd) 

77  radiant 

I.C. 

28. 

DISTANCE  FROM  TARGET  TO  MASTER  LORAN 
STATION  MINUS  DISTANCE  FROM  TARGET  TO 
SLAVE  1 

ADf 

607,600  ft 

I.C. 

29. 

DISTANCE  FROM  TARGET  TO  MASTER  LORAN  STA¬ 
TION  MINUS  DISTANCE  FROM  TARGET  TO  SLAVE  2 

AD2 

607,600  ft 

I.C. 

30. 

ELEMENT  OF  MATRIX  FOR  LORAN  TRANSFORMA¬ 
TION 

4  ft/ft 

I.C. 

31. 

ELEMENT  OF  MATRIX  FOR  LORAN  TRANSFORMA¬ 
TION 

•>12 

4  ft/ft 

I.C. 

32. 

ELEMENT  OF  MATRIX  FOR  LORAN  TRANSFORMA¬ 
TION 

•>21 

4  ft/ft 

I.C. 

33. 

ELEMENT  OF  MATRIX  FOR  LORAN  TRANSFORMA¬ 
TION 

•>22 

4  ft/ft 

I.C. 
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Table  14  (Concluded) 


DESCRIPTION  OF  VARIABLE 

FULL  SCALE 
VALUE 

OUTGOING  VARIABLES  <DP2  SIGMA  B) 

SYMBOL 

FREOUENCY 

1. 

TIME 

t 

3276.7  tec 

2. 

LATITUDE  OF  G8U-15  ESTIMATED  BY  NAVIGATOR 

^M 

TT  rartlani 

3. 

LONGITUDE  OF  GBU-16  ESTIMATED  BY 

NAVIGATOR 

/N 

•-M 

n  radiant 

50  Hz 

4. 

NORTH  VELOCITY  OF  GBU-15  ESTIMATED  BY 
NAVIGATOR 

/\ 

vn 

32,767  It/tBC 

50  Hz 

5. 

WEST  VELOCITY  OF  GBU-1S  ESTIMATED  BY  NAVI¬ 
GATOR 

v„ 

32,767  1t/tac 

SO  Hz 

6. 

UP  VELOCITY  OF  GBU  15  ESTIMATED  BY  NAVI¬ 
GATOR 

Vu 

32,767  ft/tac 

SO  Hz 

7. 

DIFFERENCE  IN  LATITUDE 

-  ^T 

1,4063  dag 

50  Hz 

8. 

DIFFERENCE  IN  LONGITUDE 

Lm-  Ly 

1.4063  deg 

50  Hz 

9. 

ERROR  IN  LATITUDE  CALCULATED  IN  KALMAN 
FILTER 

SO  Hz 

10. 

ERROR  IN  LONGITUDE  CALCULATED  IN  KALMAN 
FILTER 

50  Hz 

11. 

MIDCOURSE  STEERING  SIGNAL 

Sh 

30  units 

50  Hz 

DP2  Software 

This  subsection  describes  the  software  for  DP2  which  was  used  in 
the  simulation.  The  system  executive  is  functionally  identical  to  the  execu¬ 
tive  used  in  DPI.  The  Kalman  filter,  used  for  smoothing  the  LORAN  data, 
and  the  inertial  navigation  program  were  modified  versions  of  the  DPI  soft¬ 
ware.  These  programs  had  to  be  translated  from  the  DPI  language  to  the 
DP2  language.  The  flight  control  software  was  adapted  from  the  PDAP  flight 
control  software.  It  is  functionally  the  same  but  was  rewritten  to  put  in  a 
modular  form.  The  other  program  modules  were  written  especially  for  the 
simulation. 

The  complete  documentation  of  the  software  is  contained  in  the  Digi¬ 
tal  Processor  Software  Development  Report,  Report  No.  DGWT  0165-1. 

Functional  Descriptions.  This  subsection  describes  the  functions  performed 
by  the  DP2  software  during  the  simulations.  A  functional  block  diagram  of 
the  DP2  software  computational  elements  is  shown  in  Figure  70.  In  addition 
to  these  computational  elements,  the  System  Management  and  Executive 
software,  in  combination,  control  the  execution  of  the  DP2  software  in 
accordance  with  the  simulation  requirements  (interpretation  of  hardware 
interrupts  and  control  of  the  weapon  bus  communications  with  the  hybrid 
computer).  The  following  paragraphs  describe  the  software  elements 
including  the  relationships  between  weapon  functions  and  software 
tasks. 


Flight  Control.  The  flight  control  software  is  contained  in  three 
tasks:  27,  28, and  29.  Two  additional  tasks  (30  and  10)  are  associated  with 
the  flight  control  function  and  are  concerned  with  the  formatting  of  sensor 
data  and  transfer  of  the  data  over  the  weapon  bus. 
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CORRECTIONS 


Figure  70,  DP2  Software  Functional  Block  Diagram 

Task  29  (FCADX)  performs  rate  damping  (stabilization)  loop  compu 
tations  for  either  the  PWW  or  CWW  airframes  as  designated  by  the  flight 
control  logic.  These  computations  arc  performed  using  one  of  three  types 
of  sensor  inputs  with  the  selection  controlled  by  the  flight  control  logic. 
Actuator  commands  are  output  to  the  signal  conversion  unit  via  the  weapon 
bus  to  control  the  weapon.  Only  the  CWW  airframe  was  used,  and  rate  gyro 
signals  were  used  for  airframe  stabilization  calculations.  This  task 
queues  the  steering  calculation  task  (27  or  28)  at  a  50-Hz  rate.  Task  29 
also  contains  a  module  to  format  rate  gyro  and  accelerometer  data  for 
use  by  the  navigation  software  and  queue  the  navigation  software  at  100  Hz. 

Task  27  (COUTER)  and  Task  28  (COUTER)  perform  steering  compu 
tations  for  the  CWW  and  PWW  airframes,  respectively.  Both  of  these  tasks 
embody  a  number  of  alternative  guidance  modes  which  may  be  selected 
as  a  function  of  flight  time,  guidance  sensors,  and  airframe  dynamics. 

The  selection  is  performed  by  a  logic  module  (FCLOG)  which  is  called  by 
both  tasks.  The  steering  modes  and  mode  selection  logic  are  identical 
to  the  functions  described  in  DGWT  0160-1,  PDAP  Software  Development; 
with  the  following  exceptions.  The  yaw  heading  hold  mode  for  CWW  (only 


\ 


COUTE^R  was  used  in  the  simulation)  was  modified  to  use  yaw  steering 
commands  from  an  inertial  midcoursc  guidance  law  module  rather  than 
the  alternali\’e  DME  or  EO  data  link  commands  of  the  PDAP  flight  control 
software.  Terminal  guidance  was  performed  using  steering  commands 
from  a  simulated  ElO  seeker. 

Top  level  flow  charts  of  FCADX  and  COUTER  arc  shown  in  Figures 
71  and  tL.  The  flight  control  mode  and  sensor  selection  is  initialized  by 
calling  E^CEjOG  on  the  first  iteration  of  FCADX. after  simulated  weapon 
separation.  The  selection  is  based  on  discrete  logic  variables  received 
from  the  analog  computer  via  the  weapon  bus. 

Navigation.  The  navigation  software  calculates  weapon  position, 
velocity,  and  altitude  parameters  which  are  used  in  the  midcourse  guidance 
law.  Several  modifications  were  made  in  the  navigation  software  used  in 
DPI  tests  at  CIGTF  for  compatibility  with  the  simulation.  The  entire  gyro 
and  accelerometer  compensation  software  routine  of  IMUlOO  (Task  9)  was 
deleted  since  (1)  this  routine  was  specifically  written  for  the  Hamilton  Stan¬ 
dard  IMU  and  (2)  the  gyro  and  accelerometer  outputs  from  the  simulation 
could  be  treated  as  perfect  (the  identical  sensor  data  is  processed  in  the 
simulation  to  generate  reference  data).  However,  a  requirement  e.xists  for 
gyro  bias  compensation,  due  to  A/D  conversion  errors,  and  the  required 
software  was  inserted  in  the  IMU  data  accumulation  routine  in  FCADX, 

The  major  functional  difference  between  the  simulated  IMU  data  and 
a  true  IMU  is  that  the  hybrid  simulation  assumes  a  flat,  non-rotating  earth. 
Therefore,  the  navigation  frame  rotation  routine  was  deleted  from  IMUlOO, 
and  the  coriolis  correction  routine  was  deleted  from  IMU  10  (task  11).  A  top 
level  flowchart  of  the  navigation  software  tasks  is  shown  in  Figure  73.  The 
changes,  with  respect  to  DPI  software,  are  indicated  by  the  strikeout 
lines. 

The  navigation  software  parameters  are  initialized  by  IMUINT 
(Task  14)  in  accordance  with  digital  reference  data  from  the  SIGMA  8 
computer.  This  task  is  called  as  a  subroutine  by  System  Management 
Task  45.  During  simulated  flight,  the  navigation  parameters  are  updated 
in  accordance  with  the  rate  gyro  and  accelerometer  data  from  the  analog 
computer.  Corrections  are  made  to  the  navigation  parameters  in  flight 
by  the  alignment  filter  on  the  basis  of  position  data  from  a  LORAN  subsystem. 

Alignment.  The  DP2  alignment  software  is  virtually  a  duplicate 
of  the  DPI  alignment.  However,  the  system  operating  procedures  and 
simulation  techniques  have  caused  some  functional  differences.  The  major 
procedural  difference  is  that  the  filter  operates  throughout  the  midcourse 
phase  of  weapon  flight  rather  than  only  during  a  prelaunch  alignment  phase. 

In  the  DP2  system,  the  reference  data  is  generated  by  processing 
LORAN  signals  and  only  position  data  is  available.  Therefore,  the  filter 
was  required  to  operate  in  a  position-match- only  mode.  The  DP2  filter 
outputs  were  identical  to  the  outputs  of  the  DPI  filter;  estimates  of 
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Figure  71,  FCADX  Flowchart 
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Figure  72,  Couter  Flowchart 
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Figure  73.  Navigation  Software  Task  Flowchart 
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misalignment,  position  errors,  \-elocity  errors ,  and  gyro  biases.  The 
update  interv^al  for  gyro  bias  estimation  was  reduced  from  5  minutes  to 
12  seconds.  This  change  was  caused  by  the  expected  value  of  the  offset 
in  the  analog- to- digital  conversion  of  the  gyro  data  which  was  on  the 
order  of  40O./hour.  Similar  offsets  occur  in  the  accelerometer  data, 
but  accelerometer  biases  are  effectively  equivalent  to  misalignments 
which  are  estimated  at  each  iteration  of  the  filter. 

The  alignment  software  is  contained  in  Tasks  16,  17,  18,  21,  22, 
and  23.  The  filter  is  initialized  by  FINI,  Task  16,  which  is  queued  by 
System  Management  Task  48.  The  100--Hz  alignment  routine,  CENTSK. 
(Task  22),  is  queued  by  flight  control  Task  29  (FCADX).  Tasks  23  (TYSNC) 
and  17  (DRITSK.)  are  queued  by  the  LORAN  transformation  routine  (Task  25) 
when  it  generates  position  data  (nominal  3.  3-Hz  rate).  The  filter  control 
feedback  routine  (CONTROL,  Task  21)  is  queued  by  DRITSK.  on  each  itera¬ 
tion  to  correct  the  navigator  altitude,  velocity,  and  position  parameters. 

The  gyro  bias  correction  routine  (GYRO,  Task  18)  is  called  as  a  sub¬ 
routine  by  CONTROL  at  12-second  intervals. 


Midcourse  Guidance  Law.  The  guidance  law  calculations  are  used 
to  control  the  heading  of  the  missile  during  the  midcourse  phase  of  flight. 
In  the  simulation,  only  yaw  steering  commands  were  generated  by  the 
guidance  law  software.  Midcourse  steering  in  the  pitch  plane  came  from 
the  existing  pitch  steering  modes  of  the  GBU-15  flight  control  subsystem. 
The  guidance  law,  as  implemented,  flies  the  simulation  from  one  check¬ 
point  target  to  another  until  it  determines  that  it  is  on  the  last  segment. 
This  means  that  the  next  target  is  the  actual  target,  and  terminal  guidance 
is  enabled.  As  many  as  three  intermediate  checkpoint  targets  can  be 
used  to  shape  the  missile  flight  path  to  the  target  so  that  the  trajectory 
over  the  ground  could  have  up  to  four  segments  with  different  headings. 

The  equation  for  midcourse  guidance  which  was  implemented  is  of 
the  form; 

Steering  Command  =  ~ 


where,  is  the  missile  heading  angle  measured  from  north,  is  the 

desired  Reading  to  the  target,  and  is  the  time  rate  of  change  of  The  missile 
neading.  The  constants  Kj  and  K2  are  gain  terms  which  control  the  relative 
importance  of  the  heading  angle  steering  versus  the  angle  rate  steering  terms. 


If  (rvalues  are  in  radians  and  cr  values  are  in  radians / second,  the 
values  of  Kj  and  that  were  used  are  62.  8  and  1.  57,  respectively.  These 
values  were  selected  so  that  the  GBU-15  turning  rate  was  approximately 
equal  to  4  +  0.  1  (cjh  -  cthd)*  calculation  of  (t,  the  range  to  the  check¬ 

point  target  is  used  as  a  divisor.  To  avoid  division  by  zero,  the  next  check¬ 
point  target  was  selected  when  the  range  to  a  checkpoint  target  was  less 
than  a  thousand  feet.  At  long  ranges  from  the  next  checkpoint  target,  the 
(jpj  term  is  reduced  in  effectivity  compared  to  the  bearing  angle  term  and  the 
missile  tends  to  fly  toward  the  correct  heading  angle.  When  this  angle  is 
approached  and  as  range  to  the  next  checkpoint  target  is  diminished,  the 
6-  pj  term  gains  prominence  and  the  steering  approximates  proportional 
navigation,  which  gives  a  small  miss  distance  with  respect  to  the  check¬ 
point  target.  This  guidance  law  seemed  to  work  very  well  except  for  the 


case  where  the  initial  heading  differed  from  the  desired  heading  by  a  large 
amount.  This  caused  the  missile  to  turn  away  from  the  target  and  fly  to  the 
correct  heading  before  turning  toward  the  target.  To  correct  this  problem, 
the  ((Ttt  -  term  was  limited  to  one  degree.  This  limit  was  used  in  the 

simulation  with  satisfactory  results.  Without  the  one-degree  limit  on  the 
(o-pp  -  (Tppp))  term,  the  simulation  has  the  missile  making  a  hard  turn  toward 
the  desired  heading,  as  shown  in  Figure  74.  This  figure  shows  tyoical  yaw 
plane  trajectories  corresponding  to  <rppj^  =  30°,  (Tj^  (t  =  0)  =  0°  with  and  without 
limiting  of  the  (o-pp  -  ^-ppp))  turn  in  the  guidance  law  calculations.  The  limiting 
of  the  (o-pp  -  o'ppj]))  term  causes  the  GBU-15  to  fly  a  low  valued  constant  accel¬ 
eration  turn  until  the  desired  heading  is  reached. 

This  midcourse  guidance  law  was  implemented  both  in  the  SIGMA  8 
software  and  in  the  DP2  software  (GDLW,  Task  60).  Initialization  of  the 
DP2  guidance  law  software  parameters  in  accordance  with  data  furnished 
oy  the  SIGMA  8  computer  is  performed  by  the  subroutine,  GDLWI,  which  is 
called  by  System  Management  Task  46,  TGTINT.  Alternatively,  the 
SIGMA  8  calculation  of  yaw  midcourse  steering  commands  may  be  used. 

These  commands  are  made  available  to  the  flight  control  through  System 
Management  Task  50,  GUID. 

Top  level  flow  charts  of  GDLWI  and  GDLW  are  shown  in  Figures 
75  and  76. 
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Figure  74.  Illustration  of  Trajectories  Resulting  from  Guidance 

Law  With  and  Without  Limiting  of  (<r„-o„_)  Term  in  Calculations 
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Figure  75.  Guidance  Law  Software  Initialization 
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LORAN.  The  L.ORAN  software  (LRNX,  Task  id5)  (  alculates  weapon 
position  laased  on  digital  data  from  the  SIGMA  B  computer.  The  SIGMA  8 
simulates  the  LORAN  receiver  to  produce  path  length  differences  for  the 
two  slas  e  stations  in  the  simulated  LORAN  network.  These  two  difference 
parameters  are  calculated  and  sent  (o  DP2  at  a  50-Hz  rate.  LRNX  is 
queued  by  System  Management  Task  48  at  th.  50-Hz  rate,  hut  the  compu¬ 
tation  of  weapon  position  is  performed  at  a  3.  3  Hz  under  tne  control  of 
a  counter  within  LRNX.  Weapon  position  (latitude,  longitude)  is  calculated 
using  a  linear  transformation  from  slave  station  path  differences  to 
weapon  position  differences  relative  to  the  target  coordinates.  This 
linearization  of  the  hyperbolic  LORAN  grid  is  relative  to  the  target  posi¬ 
tion  such  that  the  algorithm  error  approaches  zero  as  the  weapon  approaches 
the  target. 

Initialization  of  the  LRNX  software  parameters  is  performed  by 
LORINT  (Task  47)  which  is  queued  by  Task  54,  both  of  which  are  in  the  System 
Management  section.  This  routine  sets  the  target  distance  difference  and 
transformation  matrix  parameters  to  values  input  from  the  SIGMA  8  computer. 

System  Management  Software.  The  system  management  software, 
in  general, is  responsible  for  interpreting  the  system  interrupts  (clock  and 
SIGMA  8),  and  controlling  the  weapon  bus  transmissions  and  the  sequencing 
of  the  other  software  modules.  In  addition,  the  System  Management  con¬ 
tains  the  routines  which  initialize  the  DP2  software  parameters,  DP2 
initialization  is  performed  in  two  parts.  The  first  part  of  initialization  is 
performed  automatically  when  the  DP2  is  started  by  pushing  the  RUN  button 
on  the  control  panel.  This  routine  initializes  the  DP2  hardware  facilities 
(memory,  index  registers,  and  flags)  to  the  appropriate  states  and  sets  up 
the  Task  ID  and  message  parameter  tables.  Following  this  initialization, 
the  DP2  enters  an  idle  loop  which  is  continually  executed  except  for  respond¬ 
ing  to  interrupts.  The  second  part  of  initialization  sets  mission-dependent 
parameters  for  the  various  computational  functions  to  values  input  from  the 
SIGMA  8  computer  (simulated  avionics  interface).  This  part  of  initializa¬ 
tion  is  performed  by  a  number  of  routines  in  response  to  SIGMA  8  inter¬ 
face  interrupts. 

The  idle  loop  has  two  functions;  maintaining  a  measure  of  idle 
time  to  facilitate  time  loading  calculations,  and  allowing  monitoring  of 
any  location  in  operand  memory  via  the  control  panel  display.  Two  condi¬ 
tional  branches  are  included  in  the  idle  loop;  The  first  branch  establishes 
an  alternative  idle  loop  path  in  which  the  weapon  separation  discrete 
from  the  analog  computer  is  accessed  and  monitored.  When  weapon 
separation  is  detected,  the  periodic  tasks  are  connected  to  the  clock 
inter rupts, and  the  alternative  idle  loop  is  disabled.  This  branch  is  ini¬ 
tially  controlled  by  a  control  panel  switch  and  is  enabled  only  if  the 
SIGMA  8  is  not  connected.  If  the  SIGMA  8  is  connected,  System  Manage¬ 
ment  Task  55  performs  the  weapon  separate  function.  The  second  branch 
provides  an  idle  loop  exit  to  the  start  of  the  initialization  routine  and  is 
used  to  allow  successive  simulation  runs  without  resetting  DP2.  This 
branch  is  controlled  by  a  flag  which  is  set  in  System  Management  Task  51 
in  response  to  a  SIGMA  8  interrupt. 
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The  other  System  Management  tasks  which  interpret  interrupts 
and  control  weapon  bus  transmissions  are  discussed  in  the  System 
Operating  Sequences. 

System  Operating  Sequences.  All  DP2  operating  sequences  arc  initiated 
by  hardware  interrupts.  The  selection  of  computational  sequences  is 
performed  by  the  appropriate  System  Management  software  task  after 
receipt  of  the  interrupt  from  the  SIGMA  8  computer  or  the  internal 
clock.  The  following  paragraphs  describe  the  processing  associated  with 
each  of  the  system  interrupts.  These  sequences  include  System  Manage¬ 
ment,  Executive,  and  applications  software  tasks  as  appropriate. 

Sigma  8  Interrupts.  The  following  sequences  pertain  to  the 
SIGMA  8  interrupts  and  the  corresponding  SIGMA  8  data  and  shown  in 
Figure  77  and  Table  15.  In  the  normal  method  of  operation  all  flags  on 
the  front  panel  are  set  low,  then  the  reset  button  is  depressed,  followed 
by  the  run  button.  This  places  the  DP  in  the  idle  loop.  \  sequence  of 
interrupts  from  the  SIGMA  8,  which  is  shown  in  Figure  78,  is  then  sent 
CO  the  DP.  Table  15  describes  the  variables  sent  to  the  DP  and  the 
reaction  of  the  DP  to  the  SIGMA  8  interrupts.  Interrupts  51  through  54 
cause  the  initialization  of  the  system.  Interrupt  51  which  sets  flag  48 
high  to  cause  the  DP  to  go  back  and  reinitialize  itself  was  included  for 
multiple  runs, all  controlled  from  the  SIGMA  8.  Interrupt  55  is  sent  after 
initialization  at  the  beginning  of  the  run.  This  interrupt  replaces  the 
weapon  separate  detection  used  with  the  analog  interface  only.  Once  the 
run  begins,  the  SIGMA  8  continues  to  send  a  periodic  sequence  of  inter¬ 
rupts,  namely,  56  followed  by  57.  These  interrupts  are  not  synchronous 
with  those  initiated  by  the  clock  within  the  DP. 

System  Initialization  Interrupt  Sequence.  When  the  SIGMA  8  com¬ 
puter  writes  51  into  the  control  word  latch  of  the  D/D  interface,  an  interrupt 
with  ID  =  51  is  sent  to  the  DP2  (see  Figure  7  8);  the  executive  module, 

IBUSIN,  is  called  when  the  interrupt  is  received  by  DP2  and  queues  up 
Task  51  (INITSY)  for  execution.  This  System  Management  task  sets  a 
flag  (49).  When  the  task  queue  is  emptied  and  execution  of  the  IDLE  loop 
is  resumed,  the  flag  (49)  is  detected  and  subroutine  INIT  is  called  to 
initialize  the  operand  memory,  flags,  and  index  registers.  Upon  comple¬ 
tion  of  initialization,  execution  returns  to  the  IDLE  loop  until  another 
interrupt  occurs. 

Pseudo-Alignment  Interrupt  Sequence.  The  initial  position,  orien¬ 
tation,  and  velocity  are  written  into  the  D/D  interface  buffer  memory, 
and  then  52  is  written  into  the  control  word  latch  by  the  SIGMA  8  compu¬ 
ter.  This  causes  interrupt  52  to  be  sent  to  DP2  (see  Figure  79).  The 
executive  module,  IBUSIN,  is  called  when  the  interrupt  is  received  and 
queues  up  Task  52  (POSITX).  POSITX  calls  the  executive  module  DBSUPR 
with  a  pointer  to  the  appropriate  data,  message  parameters.  DBSUPR 
initiates  the  transfer  of  the  initial  position,  orientation,  and  velocity 
of  the  weapon  via  the  weapon  data  bus  to  DP2.  The  completion  of  the  data 
transfer  generates  a  transfer  complete  interrupt  which  calls  the  executive 
module,  DB COMP,  which  then  queues  Task  45  (INITPS).  INITPS  moves 
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DETECTION  OF  BECKMAN  2200 
SWITCH  INDICATING  BEGINNING  OF  RUN 


SIGMA  8  SENDS  INTERRUPT  51 


SIGMA  8  SENDS  INTERRUPT  52 
DP  SENDS  INTERRUPT 

SIGMA  8  SENDS  INTERRUPT  53 


SIGMA  8  SENDS  INTERRUPT  54 


SIGMA  8  SENDS  INTERRUPT  55 

SIGMA  8  SENDS  INTERRUPT  66 

SIGMA  8  SENDS  INTERRUPT  57 
DP  SENDS  INTERRUPT 

SIGMA  8  SENDS  INTERRUPT  66 

SIGMA  8  SENDS  INTERRUPT  67 
DP  SENDS  INTERRUPT 

SIGMA  8  SENDS  INTERRUPT  66 

DETECTION  OF  BECKMAN  3200  SWITCH 
INDICATING  END  OF  RUN 

SIGMA  8  SENDS  INTERRUPT  68 


Figure  77.  Sequence  of  Interrupts  from 
SIGMA  8  to  DP 
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interrupt  51 
received  by 

D/D  INTERFACE 


interrupt  id  51 
TO  DP2 


(EXEC) 


Figure  78,  System  Initialization 
Interrupt  Sequence 
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IBUSSU 


(EXEC) 


the  data  into  operand  memory  locations,  and  the  output  buffer  then  calls 
IMUINT.  IMUINT  initializes  the  strapdown  inertial  navigation  calculations. 
This  replaces  the  alignment  sequence  which  would  be  required  to  accom¬ 
plish  the  same  results  in  an  actual  weapon  launch.  When  execution  returns 
from  IMUINT  to  INITPS,  then  the  executive  module  DBSUPR  is  called 
with  the  pointer  for  the  appropriate  data  message  parameters  to  send  the 
initial  position  and  velocity  back  to  the  D/D  interface  for  plotting  on  the 
hybrid  computer  equipment.  DBSUPR  initiates  the  transfer  of  this  output 
data  via  the  weapon  data  bus  to  the  D/D  interface.  When  the  data  trans¬ 
fer  is  completed,  a  transfer  complete  interrupt  is  generated.  This  calls 
the  executive  module  DBCOMP,  which  places  Task  49  (SIGMAI)  into  the 
task  queue.  SIGMAI  calls  the  executive  module,  IBUSSU,  with  the  param¬ 
eters  to  send  an  interrupt  to  BIU3  (D/D  interface).  The  ID  of  the  interrupt 
sent  to  the  D/D  interface  is  17,  the  number  of  words  of  data  to  be  read 
by  the  SIGMA  8  computer.  IBUSSU  sends  the  interrupt  or  control  word. 

Target  Information  Interrupt  Sequence.  The  SIGMA  8  computer 
(i;8)  sends  the  latitude,  longitude,  altitude,  and  desired  angle  of  approach 
of  the  actual  target  and  checkpoints  on  the  way  to  the  D/D  interface. 

Control  word  53  is  then  sent  to  the  latch.  This  causes  an  interrupt  with 
ID  =  53  to  be  sent  to  the  DP2.  Upon  receipt  of  the  interrupt  executive  mod¬ 
ule,  IBU3IN,  is  called  (see  Figure  80).  IBUSIN  places  Task  53  (TGTDTX) 
into  the  task  queue.  TGTDTX  calls  the  executive  module  DBSUPR  with 
a  pointer  to  the  location  where  the  parameters  which  define  the  data  trans¬ 
fer  across  the  weapon  data  bus  are  stored.  The  module,  DBSUPR,  initi¬ 
ates  the  data  transfer.  When  the  data  transfer  is  completed,  a  transfer 
complete  interrupt  is  generated.  The  executive  module,  DBCOMP,  is 
called  by  the  interrupt  which  then  places  Task  46,  TGTINT,  in  the  task 
queue.  TGTINT  move  the  target  data  from  the  input  buffer  into  operand 
memory  and  calls  subroutine,  GUIDI,  which  performs  the  calculations 
necessary  to  begin  the  midcourse  steering  guidance  law. 

LORAN  Initiali-zation  Interrupt  Sequence.  The  SIGMA  8  computer 
sends  the  LORAN  coordinates  of  the  target  (two  distance  differences)  and 
the  four  elements  of  a  matrix  used  to  describe  the  transformation  from 
change  in  distance  differences  from  the  target  to  North-South  distance 
difference  and  East-West  distance  difference.  This  data  is  followed  by 
a  control  word  which  is  54  (see  Figure  81).  An  interrupt  with  the  ID  =  54 
is  sent  to  DP2.  Executive  module,  IBUSIN,  is  called  by  the  interrupt. 
IBUSIN  places  Task  54,  LORIDX,  in  the  task  queue.  LORIDX  calls  the 
executive  module,  DBSUPR,  with  the  pointer  to  the  operand  memory 
location  where  the  parameters  describing  the  data  transfer  over  the 
weapon  data  bus  are  stored.  DBSUPR,  the  data  bus  supervisor,  causes 
the  transfer  of  the  LORAN  data  to  commence.  Upon  completion  of  the 
data  transfer,  a  transfer  complete  interrupt  is  generated  by  the  hardware. 
This  interrupt  causes  the  executive  module,  DBCOMP,  to  execute, 
DBCOMP  places  Task 47,  LORINT,  in  the  task  queue.  LORINT  moves 
the  LORAN  initialization  data  from  the  input  buffer  to  the  appropriate 
operand  memory  locations. 
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Figure  81 .  LORAN  Initialization 
Interrupt  Sequence 
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Weapon  Separate  Interrupt  Sequence.  After  the  D/D  interface 
was  integrated  into  the  simulation,  the  SIGMA  8  computer  communicated 
the  beginning  of  a  run  by  sending  control  word  55  to  the  D/D  interface. 

This  generated  an  interrupt  in  DP2  with  ID  =  55  (see  Figure  82).  The 
incoming  interrupt  caused  the  executive  module,  IBUSIN,  to  be  called. 
IBUSIN  placed  Task  55,  WEPSEP,  in  the  task  queue.  WEPSEP  called 
Systems  Management  subroutine  INITCL  which  initialized  the  memory 
location  required  to  start  the  DP2  clocked  interrupts. 

LORAN  Receiver  Interrupt  Sequence.  To  simulate  the  LORAN 
receiver,  the  SIGMA  8  computer  calculated  two  differences  in  horizontal 
distance  from  the  weapon:  (1)  distance  from  weapon  to  LORAN  master 
station  minus  distance  from  weapon  to  LORAN  above  station  number  1, 

(2)  distance  from  weapon  to  LORAN  master  station  minus  distance  from 
weapon  to  LORAN  slave  station  number  2.  These  two  distance  differences 
were  sent  to  the  D/D  interface  followed  by  control  word  56.  BIU  No.  3 
then  sent  an  interrupt  to  DP2  with  ID  =  56  (see  Figure  84  ).  This  called 
the  executive  module,  IBUSIN,  which  placed  Task  56,  LORDTX,  in  the 
task  queue.  LORDTX  calls  the  data  bus  supervisor,  DBSUPR,  with  a 
pointer  to  the  operand  memory  locations  where  the  parameters  describing 
the  desired  data  transfer  are  stored.  Based  upon  this  information, 
DBSUPR  starts  the  transfer  of  data  across  the  weapon  data  bus.  When 
the  data  has  been  transferred  over  the  weapon  data  bus  and  placed  in  the 
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Figure  82.  Weapon  Separate  Interrupt  Sequence 


DISTANCE  DIFFERENCES  AND 
CONTROL  WORD  =  56  SENT  TO 
D/D  INTERFACE  BY  SIGMA  8 


INTERRUPT  ID  =  56 
TO  DP2 


LORDTX  (TASK  56) 


(EXEC) 


TRANSFER 

COMPLETE  INTERRUPT 


FIRST  TIME  ONLY 


VIATASKQU 


LRNX  (TASK  25) 


FINI  (TASK  16) 


=  3.3  H* 

VIA  TASKQU 


V  A  TASKQU 


Figure  83,  LORAN  Receiver  Interrupt  Sequence 


input  buffer  a  transfer  complete  interrupt  is  generated.  The  transfer 
complete  interrupt  vectors  the  program  execution  to  executive  module, 
DBCOMP.  DBCOMP  places  Task  48,  LORANR,  in  the  queue.  LORANR 
moves  the  distance  differences  from  the  input  buffer  to  the  proper  operand 
memory  locations  and  calls  the  executive  module  TASKQU  to  place  Task  25, 
LRNX,  in  the  task  queue.  Approximately  every  0.  03  second  LRNX  trans¬ 
forms  the  distance  differences  into  a  latitude  and  longitude  position  of  the 
weapon  for  the  Kalman  filter  and  calls  the  executive  module  twice  to  place 
Task  23,  TSYNC,  and  then  Task  17,  DRITSK,  in  the  queue.  TSYNC 
transfers  the  contemporaneous  latitude  and  longitude  calculated  by  the 
navigator  to  another  location  in  operand  memory  and  stores  transition 
matrix  before  resetting  the  accumulators.  DRITSK.  calculates  the  posi¬ 
tion  alignment  errors  and  calls  the  executive  module  TASKQU  to  place 
Task  21,  CONTRL,  which  corrects  the  quaternion,  latitude,  and  longi¬ 
tude  of  the  navigation  into  the  task  queue. 

Midcourse  Guidance  Interrupt  Sequence.  The  SIGMA  8  computer 
calculates  the  midcourse  steering  signal  and  sends  the  value  to  the  D/D 
interface  followed  by  control  word  57.  An  intei'-rupt  with  ID  =  57  (see 
Figure  84)  is  generated  and  sent  to  DP2.  Executive  module,  IBUSIN, 
is  called  by  the  interrupt.  IBUSIN  places  Task  57,  GUIDTX,  in  the  task 
queue.  GUIDTX  calls  executive  module  DBSUPR  with  a  parameter  which 
points  to  the  memory  locations  where  the  parameters  describing  the  data 
transfer  are  stored.  DBSUPR  initiates  the  transfer  of  the  data  transfer 
over  the  weapon  data  bus.  Upon  completion  of  the  data  transfer  to  the 
input  buffer,  a  transfer  complete  interrupt  is  generated.  This  calls  the 
executive  module  DBCOMP  which  places  Task  50,  GUID,  in  the  queue. 

GUID  moves  the  steering  signal  into  operand  memory  and  writes  time, 
weapon,  latitude,  longitude,  altitude,  velocity,  North,  West,  and  up, 
and  other  output  variables  into  the  output  buffer.  The  data  bus  super¬ 
visor  DBSUPR  is  called  with  a  pointer  to  the  memory  locations  where 
the  parameters  describing  the  transfer  of  these  variables  to  BIU  No.  3  is 
stored.  DBSUPR  initiates  the  transfer  of  these  variables  over  the  weapon 
data  bus  to  the  D/D  interface  from  where  they  will  be  read  by  the  SIGMA  8 
computer  just  before  the  next  LORAN  receiver  interrupt  sequence.  A 
transfer  complete  interrupt  is  generated  when  all  of  the  data  has  been 
transferred.  This  interrupt  calls  the  executive  module  DBCOMP  which 
places  Task49,  SIGMAI,  in  the  queue.  SIGMAI  calls  the  executive  module, 
IBUSSU  with  the  parameter  to  send  an  interrupt  with  ID  =  17  to  BIU  No.  3 
which  latches  the  17  into  the  D/D  interface.  The  17  tells  the  SIGMA  8  com¬ 
puter  the  number  of  variables  it  is  to  read  on  the  next  LORAN  receiver 
interrupt  sequence. 

Run  Termination  Interrupt  Sequence,  When  the  SIGMA  8  computer 
detects  a  run  termination  condition,  it  sends  control  word  .58  to  the  D/D 
interface  (see  Figure  85).  An  interrupt  with  ID  =  58  is  received  by  the 
DP2.  The  incoming  interrupt  calls  executive  module  IBUSIN  which  then 
places  Task  58,  STOPCK,  in  the  task  queue.  STOPCK.  stops  the  clocked 
interrupts  by  zeroing  the  memory  location  which  controls  the  hardware 
clocked  interrupt  (CLKCNT  =  2181). 


(EXEC) 


(SM) 


Figure  85.  Run  Termination 
Interrupt  Sequence 

Clock  Interrupts.  The  following  sequences  are  associated  with 
clock  interrupts  which  occur  at  400-Hx  and  lO-Hz  rates.  The  clock  inter¬ 
rupts  are  enabled  when  weapon  separation  is  detected.  As  a  part  of  the 
400--Hz  sequence,  periodic  tasks  at  iteration  rates  which  are  subharmonics 
of  400  Hz,  and  which  operate  on  common  data  with  the  400-Hz  routines, 
are  queued  by  the  400-Hz  routine,  I'CADX. 

400-Hz  Interrupt  Sequence.  Every  2.  5  milliseconds  (400  Hz)  a 
clocked  interrupt  is  generated  in  the  DP2,  This  interrupt  calls  the  executive 
module  CLKINT  which  places  Task  30,  FCADI,  in  the  queue  for  execution 
(see  Figure  86).  When  FCADI  is  executed,  the  interrupt  bus  supervisor, 
IBUSSU,  is  called  with  the  proper  parameter  to  send  an  interrupt  to  BIU 
No.  2  to  signal  the  signal  conversion  unit  to  begin  converting  the  analog 
signals.  Upon  completion  of  the  A/D  conversion, an  interrupt  with  ID  =  10 
is  sent  to  the  DP2.  This  calls  executive  module  IBUSIN  which  places 
Task  10,  ADPX,  in  the  task  queue.  ADPX  calls  the  data  bus  supervisor, 
DBSUPR,  with  a  pointer  to  the  operand  memory  locations  where  the  param¬ 
eters  for  transfer  of  the  A/D  data  are  stored.  DBSUPR  initiates  the  data 
transfer  over  the  weapon  data  bus.  Completion  of  the  data  transfer 
causes  an  interrupt  to  be  generated  which  calls  executive  module  DBCOMP 
which  places  Task  29,  FCADX,  in  the  task  queue.  FCADX  moves  the 
A/D  variables  along  with  the  DLVW  into  operand  memory  and,perforrr.s 
the  400-Hz  stability  loop  calculations.  The  flipper  commands  are  written 
to  the  output  buffer,  and  the  data  bus  supervisor,  DBSUPR,  is  again  called 
with  a  pointer  to  the  location  in  operand  memory  where  the  parameter 
describing  the  transfer  of  the  flipper  commands  to  the  D/A  converters 
are  stored.  FCADX  also  places  the  outer  loop  calculations  for  the 
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flight  control  in  the  task  queue  every  eighth  iteration  by  calling  the  execu¬ 
tive  module  TASQU  with  the  task  number.  After  calling  DBSUPR,  FCADX 
call  subroutine  IMUDTX  which  accumulates  the  accelerometer  and  rate 
gyro  data  and  calls  the  executive  module  TASKQU  every  fourth  iteration 
to  place  Task  9,  IMUIOO,  and  Task  22,  CENTSK.in  the  task  queue.  IMUIOO 
performs  the  1  00-Hz  calculation  for  the  strapdown  inertial  calculations 
and  places  the  lO-Hz  and  1-H/,  strapdown  inertial  calculations  in  the  task 
queue  at  the  correct  interval.  CENTSK  performs  the  100  Hz  Kalman 
filter  accumulations. 

10-Hz  Interrupt  Sequence.  The  10-Hz  clock  interrupt  which  is 
synchronized  with  the  400-Hz  clock  interrupt  calls  CLKINT  which  places 
Task  60,  GDLW,  into  the  task  queue  to  be  executed  (sec  Figure  87). 

GDLW  performs  the  midcoursc  guidance  law  calculations. 


Figure  87.  10-Hz  Interrupt 

Sequence 


SYSTEM  INTEGRATION  AND  RUNNING  SIMULATION 

In  this  subsection,  the  integration  of  the  system  components  is 
described,  and  some  results  of  running  the  simulation  are  given. 

System  Integration 


The  integration  procedure  was  to  first  get  the  hybrid  simulation 
of  the  GBU-15  weapon  working  with  the  analog  version  of  the  cruciform 
wing  autopilot,  and  then  to  add  the  other  components,  one  by  one,  until  the 
entire  system  was  operating.  The  order  of  integration  of  the  other  compo¬ 
nents  was; 

1.  DP-2,  weapon  bus,  analog  interface,  and  the  executive  software. 

2.  The  flight  control  software. 
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3.  The  digital  int(!rfacc  between  the  weapon  bus  and  the  SIGMA  8 
computer  and  the  associated  system  management  software. 

4.  The  strapdown  inertial  navigation  software. 

5.  The  LORAN  update  subsystem.  This  included  the  simulation 
of  the  LORAN  receiver  in  the  SIGMA  8,  the  LORAN  coordinate 
transformation  software  in  the  DP,  and  the  update  data  filter 
software  in  the  DP. 

6.  The  midcourse  guidance  law  software. 

A  brief  description  of  the  major  integration  events  is  given  below.  In  the 
course  of  the  integration,  some  problems  occurred  which  have  a  bearing 
on  future  development  efforts  for  a  weapon  system  which  uses  the  core 
electronics.  These  problems  are  discussed  below. 

Digital  Autopilot  Integration.  The  digital  autopilot  had  already  been  vali¬ 
dated  in  the  earlier  PDAP  work;  however, there  were  two  changes  in  going 
from  the  PDAP  to  the  DP2  situation.  First,  the  flight  control  software  had 
been  rewritten,  as  previously  described,  to  fit  into  the  DP  modularity 
concept.  Second,  the  weapon  bus  and  the  executive  software  had  been 
added  to  the  system.  This  last  change  increases  the  transport  lag  on  the 
data  passing  through  the  DP  system.  The  results  of  the  integration 
essentially  duplicates  the  results  obtained  earlier  in  the  PDAP  simulation; 
thus, the  two  changes  mentioned  above  have  no  deleterious  effect  on  auto¬ 
pilot  performance.  Since  the  DP  simulation  adds  no  new  knowledge, 
relative  to  autopilot  performance,  from  what  was  already  learned  in  the 
PDAP  simulation,  the  detailed  results  are  not  presented  here. 

The  throughput  requirements  for  the  DP  system,  derived  in 
Volume  1  of  the  final  report,  are  based  on  the  peak  loads  occasioned  by 
the  allowed  transport  lag  for  autopilot  data.  Thus,  the  results  obtained 
in  the  simulation  verify  the  adequacy  of  the  requirements. 

While  the  DP2  flight  control  software  contains  autopilot  implemen¬ 
tations  for  both  the  planar  wing  weapon  and  the  cruciform  wing  weapon, 
only  the  latter  was  used  in  the  simulation. 

Strapdown  Inertial  Navigation.  The  software  for  the  inertial  navigation 
functions  was  derived  from  the  DPI  software  by  eliminating  some  unneces¬ 
sary  parts  as  described  in  the  DP2  Software  subsection.  No  particular  prob¬ 
lems  were  encountered  in  the  integration.  It  is  to  be  noted,  however,  that 
the  performance  of  the  software  cannot  be  checked  very  accurately  on  this 
type  of  simulation.  This  is  because  the  inertial  instruments  are  simulated 
on  the  analog  computer.  The  drifts  in  the  analog  computer  and  the  analog 
input/ output  devices  are  large  enough  to  swamp  any  inaccuracies  in  the 
navigation  software.  In  this  simulation,  the  drifts  were  large  enough  that 
errors  of  as  much  as  20  kilometers  would  be  accumulated  during  a  flight  of 
75  kilometers.  Thus,  it  is  necessary  to  have  an  update  system  in  order  to 
get  adequate  performance  in  the  simulation. 


LQRAN  Update  Subsystem.  The  LORAN  receiver  was  simulated  in  the 
SIGMA  8  computer.  The  LORAN  coordinates,  in  terms  of  distance  dif¬ 
ferences  (time  difference’s  and  speed  of  light),  were  passed  to  the  DP 
over  the  digital  interface.  These  time  difference  coordinates  were 
transformed  in  the  DP  to  the  corresponding  weapon  position  data  which 
were  then  passed  through  a  Kalman  filter.  This  filter  was  a  slightly 
modified  version  of  the  alignment  filter  used  in  the  DPI  system.  An 
interface  problem  became  apparent  when  it  was  attempted  to  integrate 
these  components.  The  problem  was  due  to  an  incompatibility  between 
the  accuracy  of  the  LORAN  position  algorithm  and  the  input  scaling  for 
the  alignment  filter. 

The  LORAN  position,  calculated  in  the  SIGMA  8,  was  determined 
by  a  linearization  of  the  basic  LORAN  equations.  The  target  position  was 
chosen  as  the  point  about  which  the  linearization  was  made.  With  this 
choice  of  expansion  point,  the  error  in  the  algorithm  goes  to  zero  when  the 
target  is  approached,  but  the  error  can  be  substantial  at  long  ranges.  The 
effect  is  to  give  a  rather  lai'ge  initial  offset  from  the  true  position,  with 
the  offset  error  going  to  a  small  value  quite  rapidly  as  the  flight  progresses. 

The  alignment  filter  was  designed  to  handle  a  large  initial  offset; 
however  after  the  initial  error  is  corrected,  the  filter  changes  scaling  so 
that  the  maximum  input  it  can  accoinmodate  is  consistent  with  the  expected 
correction  signals  it  will  obtain  in  the  alignment  process  aboard  an  air¬ 
craft.  This  scaling  did  not  have  enough  dynamic  range  to  accommodate  the 
rather  large  error  changes  accumulated  between  updates  by  the  inaccura¬ 
cies  in  the  LORAN  position  algorithm.  This  measurement  error  over¬ 
flow  caused  the  filter  to  be  ineffective  in  correcting  the  navigation  software 
parameters. 

The  problem  could  have  been  eliminated  either  by  rescaling  the 
filter  or  by  designing  a  more  accurate  LORAN  position  algorithm.  However, 
since  neither  of  these  efforts  fit  into  the  schedule,  another  solution  was 
found.  The  LORAN  position  algorithm  was  bypassed,  and  true  position 
was  sent  to  the  DP  where  it  was  filtered  by  the  Kalman  filter. 

It  should  be  pointed  out  that  the  inaccuracy  in  the  LORAN  position 
algorithm  might  not  be  a  problem  in  many  system  applications,  since  the 
error  goes  to  zero  when  the  target  is  approached.  Where  a  problem 
might  occur  is  when  it  is  desired  to  shape  the  trajectory  to  closely  follow 
some  desired  path  or  to  pass  over  some  intermediate  point.  For  this 
application,  one  or  more  additional  expansion  points  would  be  required, 
or  a  more  accurate  algorithm  would  have  to  be  found. 

It  should  also  be  noted  that,  if  it  is  desired  to  use  the  same  Kalman 
filter  for  the  alignment  and  any  of  several  update  subsystems,  the  char¬ 
acteristics  of  the  update  system  must  be  known  in  advance  so  that  the  filter 
scaling  can  accommodate  their  error  idiosyncrasies. 

As  noted  previously,  the  drift  in  the  simulated  inertial  instruments 
was  rather  large.  In  order  to  hold  the  effect  of  these  drifts  within  the  filter 
dynamic  range,  the  iteration  rate  of  the  update  was  increased  to  3.  33  Hz. 

The  design  point  for  the  filter  was  one  Hertz,  but  it  operated  well  at  the 
increased  rate. 
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Guidance  Law.  The  form  of  the  guidance  law  used  in  the  simulation  was 
described  in  the  DP2  Software  subsection.  It  was  first  implemented  on  the 
SIGMA  8  in  order  to  check  its  performance  before  coding  it  for  DP2.  In 
operating  with  the  guidance  law  in  the  SIGMA  8,  the  weapon  position,  com¬ 
puted  by  the  inertial  navigation  software  in  DP2,  was  transmitted  to  the 
SIGMA  8  over  the  digital  interface.  The  steering  signals  were  then  com¬ 
puted  with  the  guidance  law  software  in  the  SIGMA  8  and  sent  back  lo  the 
DP2  over  the  digital  interface. 


As  it  turned  out,  all  of  the  performance  data  was  taken  with  the 
SIGMA  8  version  of  the  guidance  law.  When  it  was  attempted  to  integrate 
the  version  of  the  law  coded  for  DP2,  it  was  found  that  the  system  became 
unstable.  This  was  due  to  several  logic  and  scaling  faults  in  the  code. 

By  the  time  these  problems  were  diagnosed  and  corrected,  there  was  not 
time  to  repeat  the  data  runs. 


Other  System /Software  Problems.  Two  other  problems  occurred  during 
the  integration;  one  of  them  was  in  the  hybrid  simulator,  and  the  other 
was  in  the  DP2  software. 

In  the  GBU-15  simulation,  the  E-O  terminal  guidance  function  is 
implemented  so  that,  if  the  seeker  look  angle  exceeds  30  degrees,  the 
amplifiers  will  saturate,  and  the  run  must  be  terminated.  The  look  angle 
is  computed  continuously,  even  during  midcourse,  although  E-O  guidance 
is  initiated  only  when  the  terminal  guidance  command  is  given.  Thus, 
if  the  look  angle  ever  exceeds  30  degrees  during  the  flight,  the  run  is 
terminated.  This  characteristic  put  some  limitations  on  the  kind  of 
trajectories  that  could  be  used  in  the  midcourse  guidance,  but  the  limita¬ 
tion  was  not  severe. 

A  software  problem  was  discovered  during  the  integration  of  the 
digital  interface  circuitry.  It  was  observed  that  occasionally  an  interrupt 
signal  sent  by  the  SIGMA  8  was  not  responded  to  by  the  DP.  The  problem 
was  traced  to  the  action  of  the  Idle  Loop  in  the  system  management  soft¬ 
ware.  As  previously  described,  the  Idle  Loop  sequentially  assesses  all 
operand  memory  locations  whenever  nothing  else  needs  to  be  done  by  the 
DP.  The  purpose  of  this  action  is  to  allow  monitoring  of  any  memory 
location.  For  most  operand  memory  locations  there  is  no  problem  with 
this  procedure.  In  the  case  of  the  interrupt  signal,  however,  a  problem 
can  occur.  When  an  interrupt  signal  comes  in  from  the  weapon  bus,  the 
bus  hardware  stores  the  signal  in  a  latch,  which  is  addressed  as  operand 
memory,  and  then  initiates  a  hardware  interrupt  in  the  DP  to  service  the 
incoming  signal.  Subsequent  reading  of  the  latcli  by  the  interrupt  routine 
zeros  it.  The  problem  was  due  to  the  fact  that  occasionally  the  Idle  Loop 
would  access  that  location  between  the  time  that  the  interrupt  word  was 
stored  there  and  before  the  interrupt  routine  could  be  initiated.  It  was 
solved  by  limiting  the  range  of  operand  memory  addresses  which  the 
Idle  Loop  can  access.  The  problem  is  mentioned  here  as  an  example  of 
some  of  the  rather  subtle  things  that  can  happen  in  the  interaction  of  the 
software  and  hardware. 


Running  Siniulation 


The  following  procedural  sequence  was  used  for  the  simulation  runs. 

1.  The  hybrid  simulation  was  tested  by  running  it  with  the 
analog  autopilot. 

2.  The  system  constants  were  loaded  into  the  DP2  operand  memory. 

3.  The  program  was  loaded  into  the  DP2  program  memory. 

4.  The  DP2  start  button  was  pushed  which  put  the  DP2  in  the 
Idle  Loop. 

5.  The  hybrid  computer  was  started. 

The  first  step  in  the  hybrid  computer  operation  was  for  the  SIGMA  8  to 
send  initialization  data  to  the  DP2  across  the  weapon  bus.  When  this  was 
completed,  the  weapon  separate  signal  was  sent  which  initiates  the 
flight  sequence. 

For  recording  data  from  the  DP,  the  desired  quantities  were  first 
stored  in  operand  memory  and  then  read  out  to  the  SIGMA  8  over  the 
weapon  bus.  The  SIGMA  8  transmitted  these  quantities  to  the  analog  compu¬ 
ter  where  they  were  converted  to  analog  signals  and  then  recorded  on  a 
strip  chart. 

Simulation  Run  Test  Conditions.  The  run  conditions  were  chosen  primarily 
to  evaluate  the  performance  of  the  inertial  navigation  with  update  and  the 
guidance  law,  since  the  autopilot  operation  had  been  previously  evaluated 
in  the  PDAP  simulations.  All  runs  were  made  with  the  following  launch 
condition: 

•  Altitude  =  IZ.ZKm  (40,000  feet) 

•  Range  from  target  =  73.  ZKm  (40  nautical  miles) 

•  Mach  number  =1.5 

All  trajectories  were  flown  in  a  generally  North  direction  with  the  target 
located  at  52°  North  latitude  and  12°  East  longitude. 

To  test  the  performance  of  the  inertial  navigation  and  the  guidance 
law  various  values  of  approach  angles  to  intermediate  check  points  and  the 
target  were  chosen.  These  are  listed  in  Table  l6.  In  all  of  the  runs  the 
guidance  was  switched  to  E-O  terminal  at  about  four  kilometers  from  the 
target. 

Performance  of  Midcourse  Guidance 


Representative  trajectories  for  the  conditions  given  in  Table  16 
are  shown  in  Figures  88  through  92.  Steering  in  the  vertical  plane  was 
accomplished  by  the  modes  already  in  the  GBU-15  cruciform  wing  flight 
.control  system.  Steering  in  the  horizontal  plane  was  done  by  the  midcourse 
guidance  functions  until  the  range  to  the  target  decreased  to  about  4 
kilometers  at  which  time  the  steering  was  switched  to  E-O  terminal. 

The  results  for  the  five  cases  are  discussed  below. 
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Case  1.  This  case  is  illustrated  in  Figure  88,  The  vertical  trajectory 
is  normal  for  the  cruciform  wing  weapon  and  was  essentially  the  same  for 
all  runs.  It  will  be  noted  that  the  trajectory  in  the  horizontal  plane  drifted 
off  from  the  direct  course  during  the  flight  and  then  returned  to  the  desired 
path  as  the  target  was  approached.  This  deviation  is  due  to  the  fact  that 
the  guidance  law  gain  is  not  very  high  at  large  distances  from  the  target. 

As  the  range  to  the  target  decreases,  the  gain  increases  and  pulls  the 
trajectory  back  to  the  desired  flight  path. 

At  about  4  kilometers  from  the  target,  E-O  terminal  is  switched  in 
and  the  altitude  decreases  rapidly.  The  miss  distances  for  all  cases  were 
within  acceptable  CWW  GBU-16  boundaries. 

Case  2.  In  this  case,  illustrated  in  Figure  89,  the  desired  approach  angle 
to  the  target  is  10  degrees  off  from  the  North -South  line.  The  trajectory 
veers  to  the  West  in  order  to  get  on  the  desired  approach  course  and  then 
comes  into  the  target  at  the  correct  angle. 

The  glitch  in  the  vertical  trajectory  is  due  to  the  simulation  mechani¬ 
zation  and  occurs  when  transition  to  E-O  terminal  guidance  is  made.  During 
midcourse,  before  transition  to  terminal,  the  velocity  increments  (Av's)  are 
accumulated  in  body  coordinates,  transformed  through  the  body  Euler  angles, 
and  then  integrated  to  obtain  the  range  vector  in  inertial  coordinates.  It  is 
this  range  vector  which  appears  on  the  data  record  during  midcourse.  When 
E-O  terminal  guidance  is  initiated,  the  simulation  configuration  is  changed 
so  that  the  Av's  are  transformed  through  the  gimbal  angles  and  then  inte¬ 
grated  to  obtain  the  range  vector  in  seeker  coordinates.  This  change  is 
made  to  decrease  drifts  in  the  seeker  loop  during  terminal  guidance.  During 
this  portion  of  the  flight,  the  range  vector  for  the  data  record  is  obtained  by 
transforming  from  seeker  coordinates  to  inertial  coordinates.  To  obtain  an 
initial  condition  for  the  integration  in  seeker  coordinates,  the  midcourse 
version  of  the  range  vector  is  transformed  from  inertial  coordinates  to 
seeker  coordinates.  Thus,  immediately  prior  to  transition,  the  value  of  the 
range  vector  which  appears  in  the  data  record  is  obtained  directly  from  the 
midcourse  integration.  Immediately  afterwards  it  is  the  same  value,  but  it 
has  gone  through  several  transformations:  first  from  inertial  coordinates  to 
seeker  coordinates  and  then  back  again  to  inertial  coordinates.  In  principle, 
a  discontinuity  is  not  expected;  however,  because  of  small  drifts  in  the  analog 
system,  the  transformation  matrices  are  not  perfectly  orthogonal.  There¬ 
fore,  there  is  sometimes  a  noticeable  glitch  ir  the  data  record  at  transition. 
The  glitch  has  no  significance  with  respect  to  performance  of  the  guidance 
law. 

Case  3.  This  case,  illustrated  in  Figure  90,  has  one  intermediate  check 
point  which  the  weapon  is  to  fly  over.  The  check  point  is  placed  on  the 
North-South  line  at  about  41  kilometers  from  the  target.  It  is  interesting 
to  compare  this  case  with  Case  1  which  had  the  same  desired  path  but  no 
intermediate  check  point.  In  Case  3  the  deviation  from  the  desired  path  is 
less.  This  is  because  the  course  is  initially  directed  to  the  check  point  and 
hence  the  guidance  law  gain  is  higher  during  the  first  part  of  the  flight. 
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TABLE  16.  TEST  CONDITIONS  FOR  SIMULATION  RUNS 


CASE 

NUMBER  OF 
INTERMEDIATE 
CHECK  POINTS 

CHECK  POINT  PARAMETERS 

APPROACH 
ANGLE  TO 
TARGET 

1 

CHECK  POINT  NUMBER 

2 

3 

R 

D 

A 

R 

D 

A 

R 

D 

A 

1 

0 

• 

■ 

• 

• 

• 

• 

• 

• 

• 

0 

2 

0 

• 

H 

• 

• 

* 

• 

• 

0 

• 

10 

3 

1 

42 

0 

• 

• 

• 

• 

• 

• 

0 

4 

1 

37 

2 

-4.76 

• 

• 

• 

• 

• 

• 

4.76 

5 

3 

56 

2 

-9.46 

38 

-2 

9.46 

19 

2 

-9.46 

9.46 

R  =  NORTH  RANGE  FROM  TARGET,  KILOMETERS 
O  =  EAST/WEST  OFFSET  DISTANCE  FROM  NORTH/SOUTH  LINE 
A  =■  APPROACH  ANGLE,  DEGREES  FROM  NORTH 
•  MEANS  DOES  NOT  APPLY 


SOUTH  RANGE  FROM  TARGET.  KILOMETERS 


Figure  88.  Case  1  Trajectories 
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SOUTH  RANGE  FROM  TARGET,  KILOMETERS 


WEST  EAST  RANGE  FROM  TARGET,  KILOMETERS 


Case  2  Trajectories 


SOUTH  RANGE  FROM  TARGET,  KILOMETERS 


Figure  90.  Case  3  Trajectories 
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Case  4.  This  case,  illustrated  in  Figure  91  ,  has  an  intermediate  check 
point  offset  2  kilometers  to  the  West  from  the  North-South  line.  The 
desired  angle  of  approach  to  the  check  point  is  -4.  76  degrees  and  the 
desired  angle  of  approach  to  the  target  is  +4.  76  degrees.  The  trajectory 
follows  the  desired  course  very  well. 

Case  5.  As  illustrated  in  Figure  92.  this  case  has  three  intermediate 
check  points.  It  will  be  noted  that  the  weapon  has  some  difficulty  getting 
onto  the  desired  approach  paths  for  the  second  and  third  check  points.  At 
the  third  check  point  the  trajectory  overshoots  and  does  not  pass  over  the 
point.  This  case  overstresses  the  system;  there  is  not  enough  gain  to 
successfully  accomplish  the  required  turns.  If  these  kind  of  maneuvers 
are  required,  the  guidance  law  gain  would  have  to  be  increased. 

Conclusions 


The  results  of  the  simulation  go  far  toward  validating  the  concept 
of  the  Core  electronics.  Specifically,  the  following  items  were  demonstrated; 

1.  The  Core  electronics  operating  in  a  simulated  functional 
environment  (including  interfaces)  which  would  be  typical 
of  a  real  application. 

2.  Satisfactory  performance  of  an  integrated  guidance  system 
consisting  of: 

(a)  Midcourse  inertial  guidance  with  periodic  position  updates 
(in  Core  electronics). 

(b)  E-O  terminal  guidance  (sensor  signal  processing  not  in 
Core  electronics). 

It  can  be  concluded  that  the  simulation  verified  the  adequacy  of 
the  requirements  for  the  digital  processing  system  which  were  derived  in 
Volume  I  of  the  final  report. 
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EAST  TARGET,  KILOMETERS 


Figure  91.  Case  4  Trajectories 


SOUTH  RANGE  FROM  TARGET,  KILOMETERS 


Figure  92.  Case  5  Trajectories 
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